Hi,
the point is simple. The description for the code say that TLSv1.2
should not have an valid PRF.
But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2.
But since obsoleted is set to TLSv1.2 the code part:
if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; }
Does not set the PRF to the invalid NONE as i would expected with the
description.
Gruß Thomas
> Thanks for the proposal.
>
> A general TLS/DTLS extension API and pluginable extension implementation
> is a good idea. But as there is no rules about how an extension may
> impact the handshake flow, it is not easy to define a general APIs for
> all existing known or unknown extensions and future extensions. For
> example, an extension may impact the cipher suite selection, may need to
> define new handshake messages, may need new algorithm implementation,
> may impact the algorithm used to sign handshake messages, may impact the
> algorithm used to protected application data, etc. An extension may
> impact every details of handshaking, not only the client hello and
> server hello messages. It would be great if there are general APIs that
> are simple and cover the possible impact in every details of
> handshaking. I'm open for more advices.
>
> Maybe we can have APIs to define the extension parameters, rather than
> the handshake implementation. But as we already have SSLParameters, I
> don't think we need extra APIs for extension parameters any more.
>
> JSSE is open source and an provider based framework. Alternatively,
> we'd like to accept extension implementation contributions, or developer
> can define their own private provider if necessary.
>
> Regards,
> Xuelei
>
> On 4/14/2015 1:14 AM, Thomas Lußnig wrote:
>> Hi,
>>
>> this could be an interface for such an Callback.
>> It allow hello extensions as well as handshake extensions.
>> If it would be really clean we would have an handler for:
>> - NPN
>> - ALPN
>> - Channel ID
>> - ZertificateSignature
>> - OCSP-Stapling
>> - ServerName
>> - Session Ticket
>>
>> The handler could be also used for handling:
>> - TLS_FALLBACK_SCSV
>>
>> The current way is that all these extensions are in the sun Private
>> package space
>> and to make it even worse each extension is written in another way.
>> Also i am missing an API defined way to extend the list in
>> sun.security.ssl.CipherSuite.
>>
>> Gruß Thomas
>>
>> public interface HelloHandler {
>> /**
>> * Allow to add extesions to Server/Client Hello
>> * based on the Client/Server hello */
>> public void handleHelloMessage(ClientHello clientHello, ServerHello
>> serverHello);
>> /** Allow to add new Handshake Messages based on
>> * the Client/Server Hello
>> */
>> public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream,
>> ClientHello clientHello, ServerHello serverHello);
>> /**
>> * define an order of the extensions
>> */
>> Class<? extends HelloHandler > runBefore();
>> /**
>> * define an order of the extensions
>> */
>> Class<? extends HelloHandler > runAfter();
>> }
>>
>>
>>
>>> Hi,
>>>
>>> On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd <david.ll...@redhat.com>
>>> wrote:
>>>> Do you know of a Java TLS implementation that has APIs like this already?
>>>> I
>>>> am also interested in this for the ability to implement authentication
>>>> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like
>>>> to see such an API materialize as well.
>>> I posted a while back such APIs from 3rd party JSSE implementations:
>>> http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html
>>> (at the end).
>>>
>>> The problem that has been raised is that if you offer a generic TLS
>>> extensions API, then the extension may have a semantic that it's not
>>> implemented.
>>>
>>> Imagine this TLS extensions API already existed, to add extensions to
>>> SSLEngine.
>>> Now, ALPN comes along as a new TLS extension. An application could
>>> create their own ALPNExtension subclass (extending a standard one
>>> provided by the TLS extensions API), and add it to the ClientHello.
>>> But there is no code in the JDK that calls the application, asking (on
>>> the server) to select one of the protocols, for then send back the
>>> chosen protocol to the client.
>>> This could be solved by a callback API at the moment the ClientHello
>>> is received by the server (and the ServerHello by the client), so the
>>> application can examine the ALPN protocols.
>>>
>>> The NPN extension was doing something even more complicated, creating
>>> an additional TLS message that needed to be sent at the right time.
>>>
>>> It may be that a TLS extensions API (to add/remove/query TLS
>>> extensions) *and* a callback API to analyze "hello" messages when they
>>> are received is enough to cover a lot of cases, perhaps even all
>>> currently existing ones.
>>>
>>> I asked for feedback some time ago about the status of the ALPN
>>> implementation; would be great if the security team could update the
>>> current status.
>>>
