#599 [s2s_auth_dane] Connection should fail if TLSA records do not match
Reporter
Ralf
Owner
Nobody
Created
Updated
Stars
★ (1)
Tags
Component-Community
Status-New
Type-Defect
Priority-Medium
Ralf
on
Right now, enabling "s2s_secure_auth = true" is a risky move since there are many servers out there that do not provide secure authentication. This situation is similar to the server-to-server connections for E-Mail, where again insisting on valid certificates is not practical since many, many servers do not have valid certificates. Manually maintaining a list of known-secure servers in s2s_secure_domains clearly does not scale.
The solution is the same for both e-mail and XMPP s2s connections: The server admin can announce, via DNS, that his server does support encryption, and hence this particular server should be treated accordingly, rejecting the connection if no or bad encryption (e.g., invalid cert) is provided. This is the core advantage of DANE: We can have authenticated, secure connections between servers in a world where not all servers do support authentication.
For this reason, s2s_auth_dane should make sure that if it sees a TLSA record, and if that record does not match, then the connection *must* be immediately terminated. If this does not happen, DANE does not actually gain any security on systems that have "s2s_secure_auth = false".
The behavior I am asking for is actually, probably for the reasons outlined above, mandated by the DANE RFC <https://tools.ietf.org/html/rfc6698>:
> During the TLS
> handshake, if none of the certificate associations matches the
> certificate given by the TLS server, the TLS client MUST abort the
> handshake.
Zash
on
Changes
tags Component-Community
Zash
on
Tagging issue as affecting a community module, not officially supported by the Prosody team.
Right now, enabling "s2s_secure_auth = true" is a risky move since there are many servers out there that do not provide secure authentication. This situation is similar to the server-to-server connections for E-Mail, where again insisting on valid certificates is not practical since many, many servers do not have valid certificates. Manually maintaining a list of known-secure servers in s2s_secure_domains clearly does not scale. The solution is the same for both e-mail and XMPP s2s connections: The server admin can announce, via DNS, that his server does support encryption, and hence this particular server should be treated accordingly, rejecting the connection if no or bad encryption (e.g., invalid cert) is provided. This is the core advantage of DANE: We can have authenticated, secure connections between servers in a world where not all servers do support authentication. For this reason, s2s_auth_dane should make sure that if it sees a TLSA record, and if that record does not match, then the connection *must* be immediately terminated. If this does not happen, DANE does not actually gain any security on systems that have "s2s_secure_auth = false". The behavior I am asking for is actually, probably for the reasons outlined above, mandated by the DANE RFC <https://tools.ietf.org/html/rfc6698>: > During the TLS > handshake, if none of the certificate associations matches the > certificate given by the TLS server, the TLS client MUST abort the > handshake.
Tagging issue as affecting a community module, not officially supported by the Prosody team.
Changes