search

jakartaee / servlet

Jakarta Servlet
https://eclipse.org/ee4j/servlet
Other
264 stars 85 forks source link

Expose tls_unique as request attribute #107

Open glassfishrobot opened 10 years ago

glassfishrobot commented 10 years ago

On Thu, 25 Sep 2014 11:32:41 -0400, Ron Monzillo said:

RM> In addition to the attributes currently required to be supported RM> when a request has been received over a secure protocol, consider RM> adding a requirement that that container make the value of RM> tls_unique availbale via the required to be supported (SSL) RM> attributes.

RM> tls_unique is defined in http://tools.ietf.org/html/rfc5929

RM> Access to this value will facilitate the practice of creating RM> cookies and other session identifying tokens that are bound to a RM> specific TLS connection (iow, that cannot be stolen and reused RM> outside of the TLS connection under which they were established and RM> returned).

RM> The attribute could be called: javax.servlet.request.tls_unique

RM> Note that support for this attribute above JSSE will require that RM> the value of verifyData as conveyed in the TLS finished handshake RM> message be available from the SSLSession object.

glassfishrobot commented 6 years ago
glassfishrobot commented 10 years ago

@glassfishrobot Commented Reported by @edburns

glassfishrobot commented 10 years ago

@glassfishrobot Commented markt_asf said: What feature(s) does this enable that can't be implemented based on javax.servlet.request.ssl_session_id?

What benefits would this provide over an above using SSL based session tracking as per Servlet 3.1, section 7.1.2?

glassfishrobot commented 9 years ago

@glassfishrobot Commented @edburns said: Mark, I'm not sure, but given that the feature was requested by Ron, I trust there is a valid usecase. I did some brief research and found <https://www.secure-resumption.com/>, where the following is stated:

For example the tls-unique channel binding refers to the first Finished message in the innermost handshake on the current connection, and hence by checking that this value matches on the client and server, they can presumably be assured that their communications are over the same connection.

Also, the RFC5929 Ron cites states

This definition of 'tls-unique' means that a channel's bindings data may change over time, which in turn creates a synchronization problem should the channel's bindings data change between the time that the client initiates authentication with channel binding and the time that the server begins to process the client's first authentication message. If that happens, the authentication attempt will fail spuriously.

So, I think we should add a row in the table in section 3.9 to honor Ron's request.

glassfishrobot commented 9 years ago

@glassfishrobot Commented @edburns said: More text from the RFC.

7. Required Application Programming Interfaces

TLS implementations supporting the use of 'tls-unique' and/or 'tls- unique-for-telnet' channel binding types MUST provide application programming interfaces by which applications (clients and servers both) may obtain the channel bindings for a TLS connection. Such interfaces may be expressed in terms of extracting the channel bindings data for a given connection and channel binding type. Alternatively, the implementor may provide interfaces by which to obtain the initial client Finished message, the initial server Finished message, and/or the server certificate (in a form that matches the description of the 'tls-server-end-point' channel binding type). In the latter case, the application has to have knowledge of the channel binding type descriptions from this document. This document takes no position on which form these application programming interfaces must take.

TLS implementations supporting TLS renegotiation SHOULD provide APIs that allow applications to control when renegotiation can take place. For example, a TLS client implementation may provide a "callback" interface to indicate that the server requested renegotiation, but may not start renegotiation until the application calls a function to indicate that now is a good time to renegotiate.

glassfishrobot commented 10 years ago

@glassfishrobot Commented Issue-Links: is cloned by SERVLET_SPEC-151 duplicates SERVLET_SPEC-151

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA SERVLET_SPEC-107

glassfishrobot commented 6 years ago

@DDvO Commented A pity that this has not been implemented yet despite this feature request of 2014. We would have needed it for an EST server implementation.

In EST (Enrollment over Secure Transport) the tls-unique is essential to bind the TLS-level proof of origin (i.e., client authentication) to the the proof-of-possession implemented as a self-signature of the (PKCS#10-like) certificate request. This is achieved by placing the current tls-unique value inside the signed body of the PKCS#10 request.

Neustradamus commented 11 months ago

Any progress on it?

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

Little details, to know easily:

Thanks in advance.

Linked to:

grgrzybek commented 11 months ago

Wow - a long history here...