On 2015-11-06 14:55, Travis Burtrum wrote: > On 11/06/2015 08:24 AM, Kim Alvefur wrote: >> On 2015-11-06 11:28, Georg Lukas wrote: >>> * Travis Burtrum <[email protected]> [2015-11-05 20:56]: >>>> That was a deliberate decision on my part, and does not affect >>>> security in the way you mentioned because I explicitly state: >>>>> TLS certificates MUST be validated the same way as for >>>>> STARTTLS. >>>> (ie, as specified in XMPP Core). >>> >>> So lets assume I want to connect as [email protected] and the >>> SRV record is >>> >>> _xmpp-client._tls.example.com. IN SRV 5 1 443 xmpp.example.com. >>> >>> My client then makes a TCP connection to xmpp.example.com:443, >>> requests xmpp.example.com via SNI, and the server is expected to >>> return the certificate for example.com instead, which the client >>> verifies? > >> That's ... unpleasant. At least Prosody has absolutely no idea >> what SRV targets point at it. Suppose you could index all >> configured certificates on what names they claim. > > Prosody doesn't support SNI for xmpp-over-tls at all currently, if > this XEP moves further along I was going to start writing patches for > that.
I was actually working on that the other day. Support for SNI doesn't make it easier if the SNI name does not match any local service names, only SRV targets, which could be anything. This applies to policy decisions too, maybe I want two separate XMPP hosts to have different cipersuites, which would be impossible without having one SRV target for each service, which negates the benefit of SRV records. -- Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
