On 09/25/2015 10:13 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd <david.ll...@redhat.com> wrote:
Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine
to specify the selected protocol; this would be done during setup before you
initiate handshake (which is why you need to explore the Hello packet in the
first place).
You also need to add another method to specify the cipher suite that
goes along with the application protocol.
No you wouldn't, because there already is a method for that:
setEnabledCipherSuites(). You can only send one protocol back in the
response, so there's nothing else to do. Matching suites to protocols
is the responsibility of the application protocol developer and must be
done before handshake.
We have already discussed this approach: it's the "tuple" approach
where the application is given the list of TLS protocols, the list of
ciphers, the list of application protocols, the list of aliases and
decides what is the right tuple, and return that to the JDK.
Also, what if the JDK implementation refuses to use the cipher you
chose along with the application protocol, for whatever reason ?
Then you'd get an alert, I'd expect.
That would be wrong, because you could actually speak another protocol.
If you could, then the server would have chosen another protocol before
handshake even begins.
But my point is that it's not the
JDK's business to introspect the application protocol! The JDK should only
be looking at (TLS) protocol and cipher suite as it does today. It's up to
the application protocol to determine if there are unacceptable cipher
suites for that protocol. Any other approach is inherently broken! What if
I add a new application protocol, and some cipher suites are unacceptable
for it? Should I just rely on the JDK for half the time? Definitely not -
the protocol implementation *must* be fully responsible for its own security
policy.
I don't understand where you got the impression that the JDK has to
inspect the application protocol.
We are discussing an API exposed by the JDK to applications, exactly
because the application decides whether to accept or not the
combination of application protocol, cipher, etc.
Yes, but doing so by SSLContext is already too late in many cases.
Trying to make a hook into handshaking is the wrong way of looking at
this. The user needs to make decisions *before* handshaking is even
initiated on the server.
--
- DML
