> On 6 nov. 2015, at 14:15, Travis Burtrum <[email protected]> wrote: > > On 11/06/2015 05:28 AM, Georg Lukas wrote: > > So lets assume I want to connect as [email protected] > > <mailto:[email protected]> and the SRV > > record is > > > > _xmpp-client._tls.example.com <http://tls.example.com/>. IN SRV 5 1 443 > > xmpp.example.com <http://xmpp.example.com/>. > > > > My client then makes a TCP connection to xmpp.example.com > > <http://xmpp.example.com/>:443, > > requests xmpp.example.com <http://xmpp.example.com/> via SNI, and the > > server is expected to > > return the certificate for example.com <http://example.com/> instead, which > > the client > > verifies? > > > > If this is the desired behavior, it must be stated VERY CLEARLY in > > the XEP, as it is very unintuitive. > > Yes that's exactly how I intended it to work. The server operator > would know which domain to serve which certificate for because they > set it up that way. The plus side being this gives the server an easy > way to route traffic (as opposed to just example.com <http://example.com/> > being sent) and I > can't see any negatives. > > It would make sense to explain it better and more thoroughly.
One negative is that it would make things a lot more complicated for shared hosting providers. If you create records like: _xmpp-client._tls.example.com. IN SRV 5 1 5223 xmpp.hoster.lit then it would be difficult for the hoster to serve the right certificate if the SNI indicates only "xmpp.hoster.lit". They could identify by port, or by wildcard DNS entries like example.com.xmpp.hoster.lit, but that complicates the configuration for example.com. (Sure, most existing XMPP hosting provides don't serve valid certificates, but that's not a good reason to make it *harder*.) Thijs
signature.asc
Description: Message signed with OpenPGP using GPGMail
