RFC 5929: Channel Bindings for TLS: tls-server-end-point support

[Neustradamus]

Dear @jakartaee team,

Can you add the missing "tls-server-end-point" support of RFC 5929: Channel Bindings for TLS?

• https://datatracker.ietf.org/doc/html/rfc5929
• https://www.rfc-editor.org/rfc/rfc5929#section-4

In more, there are:

• XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
• XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
• XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
• XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

Little details, to know easily:

• tls-unique for TLS =< 1.2 (RFC5929)
• tls-server-end-point =< 1.2 + 1.3 (RFC5929)
• tls-exporter for TLS = 1.3 (RFC9266)

After the jabber.ru MITM, it is time to add it:

• https://notes.valdikss.org.ru/jabber.ru-mitm/
• https://snikket.org/blog/on-the-jabber-ru-mitm/
• https://www.devever.net/~hl/xmpp-incident
• https://blog.jmp.chat/b/certwatch/certwatch

Thanks in advance.

Linked to:

• Channel Binding: State of Play scram-sasl/info#1

[markt-asf]

The Servlet API can't perform the channel binding but it can expose the necessary information from the Java API for a higher layer to perform the channel binding.

This binding is based on the server certificate. That information is readily available.

The information can be exposed as a request attribute . I propose doing this under the name jakarta.servlet.request.ssl_server_certificate. The exact format is TBD but byte[] is most likely which can then be hashed as required to create the binding. The only question at this point is that the bytes need to be identical to those used in the server's certificate message. That shouldn't be a problem but we do need to confirm that.