Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
Am 01.07.19 um 10:08 schrieb Dave Cridland:
[...]
Do you know which server implementations currently support both TLS and
non-TLS (with STARTLS) on the same port?
I have a vague recollection that Fippo mentioned this trick years ago -
perhaps Psyc, perhaps even the original Jabberd?
psyced supports that, as well as good old jabberd14.
Servers can do this by trying a (non-destructive) XML parse on the data,
and if that fails (with any error other than EOF), try interpreting it as a
TLS ClientHello handshake message. I think you could probably make some
heuristic based on the first character, too, and I think that's what Fippo
mentioned.
the heuristic works the other way round. You peek the first byte (i.e.
call recv with MSG_PEEK) .
0x16 means a TLSv1 record (and I think newer versions too), 0x80 or 0x00
indicate the evil SSLv2 (skip this), 0x3c ('<') is actually xml you can
feed into your xml parser. You can also demultiplex this on port 80 or
443 and run your web server along with your xmpp server.
If I say "Fippo" a third time, I think it summons him and he might
comment...
it does :-)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, 30 Jun 2019 at 17:31, Ralph Meijer wrote: > On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited > wrote: > >On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote: > >> Hmm. On which port? I want to point out explicitly that although 5223 > >> has been used a bunch since before the IETF standardization, IANA has > >> assigned it to some HP management service. Hence my other proposal, > >> which is still currently unregistered. > > > >5222, assuming a client connection, probably. If we ever got a port > >registered for xmpps-client, I'd probably switch it to that. Although > >right now it seems fine to do both on 5222. > > Do you know which server implementations currently support both TLS and > non-TLS (with STARTLS) on the same port? I have a vague recollection that Fippo mentioned this trick years ago - perhaps Psyc, perhaps even the original Jabberd? Servers can do this by trying a (non-destructive) XML parse on the data, and if that fails (with any error other than EOF), try interpreting it as a TLS ClientHello handshake message. I think you could probably make some heuristic based on the first character, too, and I think that's what Fippo mentioned. If I say "Fippo" a third time, I think it summons him and he might comment... Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019, at 20:33, Kim Alvefur wrote: > You can detect it, it's advertised in DNS. The point of this is a fallback in case it's not advertised in DNS. > Since a common use case of Direct TLS is to put it on port 443, why > don't you also probe that port? That might be a good idea too. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019 at 06:23:36PM +, Sam Whited wrote: > On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote: > > Please don't. While detecting use of TLS or plain is fairly simple it > > is more complicated to handle both on the same port. I don't know any > > socket handling framework that makes this easy. Usually the TLS > > library takes over the socket and if you inspected the first bytes > > then it fails. > > You don't have to support them both on the same port necessarily, but > since I can't detect if you support it or not I don't have many options > other than to just try it. You can detect it, it's advertised in DNS. Since a common use case of Direct TLS is to put it on port 443, why don't you also probe that port? -- Zash signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 12:32:07 PM EDT, Ralph Meijer wrote: >Do you know which server implementations currently support both TLS and >non-TLS (with STARTLS) on the same port? If you put sslh in front of them, all servers do. Try burtrum.org:443 for instance. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote: > Please don't. While detecting use of TLS or plain is fairly simple it > is more complicated to handle both on the same port. I don't know any > socket handling framework that makes this easy. Usually the TLS > library takes over the socket and if you inspected the first bytes > then it fails. You don't have to support them both on the same port necessarily, but since I can't detect if you support it or not I don't have many options other than to just try it. > Trying direct TLS on a starttls port will usually result in garbage > being fed to the XML parser, which leads to very loud error messages, > possibly even including thing garbage. That seems like a terrible (and possibly dangerous) thing for a framework to do. If this is true I'd argue that your XML parser or server is broken. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019 at 04:55:47PM +, Sam Whited wrote: > On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote: > > Do you know which server implementations currently support both TLS > > and non-TLS (with STARTLS) on the same port? > > I'm sure if any of them do, but the fallback would still be useful in > case the service is only configured to support direct TLS on the > regular port. Please don't. While detecting use of TLS or plain is fairly simple it is more complicated to handle both on the same port. I don't know any socket handling framework that makes this easy. Usually the TLS library takes over the socket and if you inspected the first bytes then it fails. Trying direct TLS on a starttls port will usually result in garbage being fed to the XML parser, which leads to very loud error messages, possibly even including thing garbage. I's annoying enough when some clients do this, don't legitimize it. -- Regards, Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote: > Do you know which server implementations currently support both TLS > and non-TLS (with STARTLS) on the same port? I'm sure if any of them do, but the fallback would still be useful in case the service is only configured to support direct TLS on the regular port. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote: >> Hmm. On which port? I want to point out explicitly that although 5223 >> has been used a bunch since before the IETF standardization, IANA has >> assigned it to some HP management service. Hence my other proposal, >> which is still currently unregistered. > >5222, assuming a client connection, probably. If we ever got a port >registered for xmpps-client, I'd probably switch it to that. Although >right now it seems fine to do both on 5222. Do you know which server implementations currently support both TLS and non-TLS (with STARTLS) on the same port? -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote: > Hmm. On which port? I want to point out explicitly that although 5223 > has been used a bunch since before the IETF standardization, IANA has > assigned it to some HP management service. Hence my other proposal, > which is still currently unregistered. 5222, assuming a client connection, probably. If we ever got a port registered for xmpps-client, I'd probably switch it to that. Although right now it seems fine to do both on 5222. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 5:07:08 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote: >> Just to be clear, in the same way as for xmpp-client, as per RFC >2782? > >I think so; I meant by fetching the A/ record of the domain part of >the JID, and then attempting to perform direct TLS if a connection is >established. Then again, if an attacker can poison my DNS to send me a >"." SRV record, they can probably mess with the A/ records too so I >suppose it doesn't matter all that much. > >Either way, if a connection is made at some point I'll probably try >direct TLS whether it was advertised or not. Hmm. On which port? I want to point out explicitly that although 5223 has been used a bunch since before the IETF standardization, IANA has assigned it to some HP management service. Hence my other proposal, which is still currently unregistered. -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote: > Just to be clear, in the same way as for xmpp-client, as per RFC 2782? I think so; I meant by fetching the A/ record of the domain part of the JID, and then attempting to perform direct TLS if a connection is established. Then again, if an attacker can poison my DNS to send me a "." SRV record, they can probably mess with the A/ records too so I suppose it doesn't matter all that much. Either way, if a connection is made at some point I'll probably try direct TLS whether it was advertised or not. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 4:45:40 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote: >> 1) It's not A/ fallback "as per RFC 6120", because we're talking >>about a Direct TLS fallback. It should be per section... erm... >> 2) This document doesn't mention a A/ fallback at all, and >perhaps >>that's right - do we ever want one with '368? >> > Please comment on-list. > >I've been meaning to change my library to do its fallback a little >differently, including trying direct TLS fallback A/ fallback. DNS >often doesn't use any sort of security measures, so to prevent DNS >based >downgrade attacks it seems best to me to always try direct TLS on the >A/ record, just as we always try StartTLS even if it's not >advertised. Just to be clear, in the same way as for xmpp-client, as per RFC 2782? -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote: > 1) It's not A/ fallback "as per RFC 6120", because we're talking >about a Direct TLS fallback. It should be per section... erm... > 2) This document doesn't mention a A/ fallback at all, and perhaps >that's right - do we ever want one with '368? > > Please comment on-list. I've been meaning to change my library to do its fallback a little differently, including trying direct TLS fallback A/ fallback. DNS often doesn't use any sort of security measures, so to prevent DNS based downgrade attacks it seems best to me to always try direct TLS on the A/ record, just as we always try StartTLS even if it's not advertised. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 11:53:39 AM GMT+02:00, Dave Cridland wrote: > [..] >OK, two comments, which are essentially both my fault: > >1) It's not A/ fallback "as per RFC 6120", because we're talking >about >a Direct TLS fallback. It should be per section... erm... >2) This document doesn't mention a A/ fallback at all, and perhaps >that's right - do we ever want one with '368? I think we should have a fallback, though. RFC 2782, in the section about "Usage rules", clearly specifies the resolution procedure, which includes a fallback using A/ records. E.g. in Twisted, SRV resolution is protocol agnostic, and behalves as in the RFC. Also, and more importantly, I think it is good for consistency. I believe this also means that when we register the service name with IANA, we have to provide a port number. I suggest 5857, and leave the "why this one?" as an exercise to the reader. -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, 30 Jun 2019 at 09:40, Jonas Schäfer wrote:
> On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> > On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> > > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> > >
> > > jo...@wielicki.name> wrote:
> > > >Hi list,
> > > >
> > > >It is not clear to me how to interpret, in a library connecting to an
> > > >XMPP
> > > >service, a single SRV record for _xmpps-{client,server} which has `.`
> > > >as the
> > > >target.
> > > >
> > > >For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
> > > >`.`
> > > >indicates that the domain does not host an XMPP service at all, so
> > > >attempting
> > > >to form a connection should stop right there (most notably, no
> fallback
> > > >to
> > > >domainpart A/ lookup).
> > > >
> > > >How should this be interpreted for XEP-0368? Should a `.` indicate "I
> > > >do not
> > > >speak direct TLS, but try _xmpp-client records"? Or should it
> indicate,
> > > >right
> > > >away, that there is no XMPP service on the domain?
> > >
> > > According to RFC 2782 it means the service xmpps-client is not
> available
> > > at this domain. So I think the answer should be the former. If there
> is a
> > > similar record for xmpp-client, though, you can't connect the regular
> way
> > > either. Maybe there's still another binding (BOSH, WebSocket) that
> could
> > > succeed, but
> > > defining all possible permutations is a bit much.
> >
> > I think:
> >
> > 1) A client ought to, if possible, send the two DNS queries in parallel.
> > 2) If this isn't the case, there's no "right" order.
> > 3) Therefore it'd be possible to obtain some records from _xmpp-client,
> but
> > afterward get a '.' from _xmpps-client.
> > 4) Therefore the only sensible interpretation is that it says direct TLS
> > (xmpps-client) is not supported, and says nothing about the traditional
> > method (xmpp-client).
> >
> > > >Whatever the consensus is, this should be written down in the XEP I
> > > >think.
> > >
> > > Agreed.
> >
> > I'm always for documenting things.
> >
> > May as well note here that the '.' target explicitly prevents use of the
> > fallback A/ resolution.
>
> Thanks for your feedback folks.
>
> Here’s a proposal: https://github.com/xsf/xeps/pull/796
>
>
OK, two comments, which are essentially both my fault:
1) It's not A/ fallback "as per RFC 6120", because we're talking about
a Direct TLS fallback. It should be per section... erm...
2) This document doesn't mention a A/ fallback at all, and perhaps
that's right - do we ever want one with '368?
> Please comment on-list.
>
> kind regards,
> Jonas___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> >
> > jo...@wielicki.name> wrote:
> > >Hi list,
> > >
> > >It is not clear to me how to interpret, in a library connecting to an
> > >XMPP
> > >service, a single SRV record for _xmpps-{client,server} which has `.`
> > >as the
> > >target.
> > >
> > >For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
> > >`.`
> > >indicates that the domain does not host an XMPP service at all, so
> > >attempting
> > >to form a connection should stop right there (most notably, no fallback
> > >to
> > >domainpart A/ lookup).
> > >
> > >How should this be interpreted for XEP-0368? Should a `.` indicate "I
> > >do not
> > >speak direct TLS, but try _xmpp-client records"? Or should it indicate,
> > >right
> > >away, that there is no XMPP service on the domain?
> >
> > According to RFC 2782 it means the service xmpps-client is not available
> > at this domain. So I think the answer should be the former. If there is a
> > similar record for xmpp-client, though, you can't connect the regular way
> > either. Maybe there's still another binding (BOSH, WebSocket) that could
> > succeed, but
> > defining all possible permutations is a bit much.
>
> I think:
>
> 1) A client ought to, if possible, send the two DNS queries in parallel.
> 2) If this isn't the case, there's no "right" order.
> 3) Therefore it'd be possible to obtain some records from _xmpp-client, but
> afterward get a '.' from _xmpps-client.
> 4) Therefore the only sensible interpretation is that it says direct TLS
> (xmpps-client) is not supported, and says nothing about the traditional
> method (xmpp-client).
>
> > >Whatever the consensus is, this should be written down in the XEP I
> > >think.
> >
> > Agreed.
>
> I'm always for documenting things.
>
> May as well note here that the '.' target explicitly prevents use of the
> fallback A/ resolution.
Thanks for your feedback folks.
Here’s a proposal: https://github.com/xsf/xeps/pull/796
Please comment on-list.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> jo...@wielicki.name> wrote:
> >Hi list,
> >
> >It is not clear to me how to interpret, in a library connecting to an
> >XMPP
> >service, a single SRV record for _xmpps-{client,server} which has `.`
> >as the
> >target.
> >
> >For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
> >`.`
> >indicates that the domain does not host an XMPP service at all, so
> >attempting
> >to form a connection should stop right there (most notably, no fallback
> >to
> >domainpart A/ lookup).
> >
> >How should this be interpreted for XEP-0368? Should a `.` indicate "I
> >do not
> >speak direct TLS, but try _xmpp-client records"? Or should it indicate,
> >right
> >away, that there is no XMPP service on the domain?
>
> According to RFC 2782 it means the service xmpps-client is not available
> at this domain. So I think the answer should be the former. If there is a
> similar record for xmpp-client, though, you can't connect the regular way
> either. Maybe there's still another binding (BOSH, WebSocket) that could
> succeed, but
> defining all possible permutations is a bit much.
>
>
I think:
1) A client ought to, if possible, send the two DNS queries in parallel.
2) If this isn't the case, there's no "right" order.
3) Therefore it'd be possible to obtain some records from _xmpp-client, but
afterward get a '.' from _xmpps-client.
4) Therefore the only sensible interpretation is that it says direct TLS
(xmpps-client) is not supported, and says nothing about the traditional
method (xmpp-client).
>
> >Whatever the consensus is, this should be written down in the XEP I
> >think.
>
> Agreed.
>
>
I'm always for documenting things.
May as well note here that the '.' target explicitly prevents use of the
fallback A/ resolution.
>
> --
> Cheers,
>
> ralphm
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer"
wrote:
>Hi list,
>
>It is not clear to me how to interpret, in a library connecting to an
>XMPP
>service, a single SRV record for _xmpps-{client,server} which has `.`
>as the
>target.
>
>For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
>`.`
>indicates that the domain does not host an XMPP service at all, so
>attempting
>to form a connection should stop right there (most notably, no fallback
>to
>domainpart A/ lookup).
>
>How should this be interpreted for XEP-0368? Should a `.` indicate "I
>do not
>speak direct TLS, but try _xmpp-client records"? Or should it indicate,
>right
>away, that there is no XMPP service on the domain?
According to RFC 2782 it means the service xmpps-client is not available at
this domain. So I think the answer should be the former. If there is a similar
record for xmpp-client, though, you can't connect the regular way either. Maybe
there's still another binding (BOSH, WebSocket) that could succeed, but
defining all possible permutations is a bit much.
>Whatever the consensus is, this should be written down in the XEP I
>think.
Agreed.
--
Cheers,
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
Hi list,
It is not clear to me how to interpret, in a library connecting to an XMPP
service, a single SRV record for _xmpps-{client,server} which has `.` as the
target.
For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a `.`
indicates that the domain does not host an XMPP service at all, so attempting
to form a connection should stop right there (most notably, no fallback to
domainpart A/ lookup).
How should this be interpreted for XEP-0368? Should a `.` indicate "I do not
speak direct TLS, but try _xmpp-client records"? Or should it indicate, right
away, that there is no XMPP service on the domain?
Whatever the consensus is, this should be written down in the XEP I think.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
