Logs for jdev

Show join/part/nick changes:

[00:38:39] * Xificurk joined the chat.
[01:28:53] * Florob left the chat.
[02:06:22] * xnyhps joined the chat.
[02:07:09] * Link Mauve joined the chat.
[07:03:33] * darkrain joined the chat.
[08:21:56] * Asterix joined the chat.
[09:17:56] * Asterix left the chat.
[09:18:07] * Asterix joined the chat.
[09:43:12] <Asterix> Hi all, I have a question about SSL certificat for a jabber server. Client should check if the CN of the certificate is correct, but to what should it compare it? host of the machine returned by SRV records? domain name of the jid? something else?
[09:46:34] <Zash> The CN should be the last resort thing to check
[09:47:33] <Zash> IIRC (it's in xmpp-core), you should check (id-on-xMPPAddr), sRVName, dNSName, CN
[09:47:40] <Zash> in that, or some similar order
[09:48:32] <Zash> http://tools.ietf.org/html/rfc6120#section-13.7.2.1
[09:48:56] <Asterix> ok thanks, I read that
[09:50:21] <Zash> This entire section would be relevant, http://tools.ietf.org/html/rfc6120#section-13.7 :)
[09:50:33] <Zash> Along with the over 9000 RFCs referenced ;P
[09:51:22] <Asterix> ok, a lot of things to read :)
[09:51:23] <Asterix> thanks
[09:51:28] <Zash> yw :)
[09:53:51] * harrykar left the chat.
[09:53:54] * harrykar joined the chat.
[09:57:44] <Zash> This be what prosody does: http://hg.prosody.im/trunk/file/tip/util/x509.lua#l147
[09:58:59] <Asterix> Do you know a server that offer a certificat with all those fields so I can see if my library shows me those fields?
[09:59:12] <Asterix> on the one on jabber.org I can only see CN
[09:59:44] <Zash> Most from CAcert has those fields
[10:01:59] <Zash> Asterix: http://q.zash.se/e9bd5500.txt
[10:02:16] <Zash> That's openssl config to generate that cert
[10:04:25] * scippio joined the chat.
[10:08:21] <Asterix> ok it seems the library needs to support subjectAltName, then I don't think my library (pyopenssl) supports that
[10:08:28] <Zash> http://q.zash.se/bf032dc3.txt
[10:08:32] <Zash> :(
[10:09:50] <Zash> jabber.org's has dns- srv- and xmppaddr SANs
[10:09:57] <Asterix> ok
[10:11:53] <Zash> https://bugs.launchpad.net/pyopenssl/+bug/385178 https://bugs.launchpad.net/pyopenssl/+bug/400937 https://bugs.launchpad.net/pyopenssl/+bug/892522
[10:15:15] <Asterix> first report, point 8 is what I need
[10:17:44] <Zash> 1½ year old bug with patch :(
[10:17:50] <Asterix> ok then we cannot check certificate at all without those extensions. RFC says CN is a string like "Example Products, Inc."
[10:18:17] <Zash> In a perfect world, yes.
[10:18:54] <Zash> But since support for SANs seem to suck everywere, we now have a situation where everyone thinks that the CN should be the hostname :(
[10:20:47] <Asterix> hostname of the machine or of the jid? if jid is user@example.org and SRV says server is on machine.example.org, CN is example.org or machine.example.org?
[10:21:14] <Zash> the domain part of the jid
[10:21:50] <Asterix> ok, than I could test that, but I'm n ot sure it's a so good idea ...
[10:21:59] <Zash> Better than nothing :(
[10:22:24] <Asterix> really? server that follow the RFC will produce an error for my client
[10:22:35] <Zash> The server hostname from the SRV lookup would be bad tho, if an attacker can fake DNS replies
[10:24:06] <Zash> It's pretty much a de facto standard to have CN=hostname
[10:26:29] <Zash> http://tools.ietf.org/html/rfc6125#section-6.4.4
[10:29:04] <Asterix> ok, I'll go for that for the moment, thanks
[10:29:06] <Zash> https://lists.launchpad.net/pyopenssl-users/msg00008.html
[10:29:17] <Zash> * The peer's certificate chain for a connection can now be inspected. * New methods have been added to PKey and X509 objects exposing more OpenSSL functionality.
[10:31:00] * Tobias joined the chat.
[10:31:06] <Zash> http://packages.python.org/pyOpenSSL/openssl-x509.html -- http://packages.python.org/pyOpenSSL/openssl-x509.html#l2h-62
[10:32:13] <Asterix> haaa
[10:33:05] <Zash> Is it too late to bug ubuntu about including that version in the next release?
[10:33:38] <Zash> If that is indeed what it sounds like :)
[10:33:44] <Asterix> doc on sourceforge is not uptodate :/
[10:33:48] <Asterix> http://pyopenssl.sourceforge.net/pyOpenSSL.html/openssl-x509.html
[10:34:15] <Zash> http://pyopenssl.sourceforge.net/ links to the new docs
[10:50:51] <Asterix> Yeah! http://pastebin.com/DnG5cdJM I now have to decode that. Thanks a lot Zash
[10:51:07] <Zash> lolwut
[11:44:17] <Asterix> What a pain to decode ASN.1 !!!
[11:45:19] <Zash> Why .. isn't it doing that for you?
[11:48:50] <Asterix> I found that: http://stackoverflow.com/questions/5519958/how-do-i-parse-subjectaltname-extension-data-using-pyasn1
[11:49:05] <Asterix> pyopenssl only gives the ASN.1 encoded string
[11:49:19] <Zash> Slap them
[11:54:14] * Tobias left the chat.
[12:19:03] * xnyhps left the chat.
[12:31:37] * tkoski joined the chat.
[12:32:03] * tkoski left the chat.
[12:40:12] * Tobias joined the chat.
[12:52:16] * Tobias left the chat.
[13:19:11] * Tobias joined the chat.
[13:21:25] * Florob joined the chat.
[13:50:57] * naw joined the chat.
[13:57:28] <Asterix> ok I can decode it now. But I still have 2 questions: it seems order of verification is: 1. dNSName 2. otherName->SRV-ID (1.3.6.1.5.5.7.8.7) 3. otherName->XmppAddr (1.3.6.1.5.5.7.8.5) 4. CN That's not the order prosody checks. Is that normal? second question: jabber.org cert, for SRV-ID field, has "jabber.org" and "*.jabber.org", while it shoud be _xmpp-client.jabber.org and xmpp-server.jabber.org am I wrong?
[14:01:19] <Zash> I'd consider XmppAddr to be the most specific (This is valid for this XMPP JID), then sRVName (This is valid for this service at this domain), then dNSName, then CN
[14:02:42] <Asterix> Does that mean that the order in RFC doesn't count?
[14:03:06] <Asterix> http://tools.ietf.org/html/rfc6120#section-13.7.1.2.1
[14:05:13] <Zash> Is there an specific order mentioned there?
[14:05:44] <Florob> No there isn't. The specific order is in TLS-CERTS as referenced there
[14:10:40] <Zash> I can't find any specific order requirement, except for "Don't check CN if there is any SANs" (But then, I'm a bit tired)
[14:12:34] <Asterix> ok thanks, I'll go for that then
[14:13:08] <Zash> Oh, look, a reference to 'HTTP over TLS', yay RFC hunting
[14:13:43] <Zash> and PKIX
[14:17:45] * scippio left the chat.
[14:19:56] <Florob> Zash, you are right. It's a logical or anyway, so the order doesn't really matter
[14:20:12] <Zash> Yeah.
[14:22:13] <Zash> Except for CN that must not be checked if there are any SANs.
[14:22:50] <Florob> Well, it's more specific. No DNS-ID, SRV-ID or URI-ID. There could be still other SANs AFAIK
[14:23:39] <Zash> Ah, yes. http://tools.ietf.org/html/rfc6125#section-6.4.4
[14:34:20] <Asterix> second problem with jabber.org cert: it seems *.jabber.org for the XmppAddr isn't valid
[14:34:44] * jcea joined the chat.
[14:36:39] <Zash> Nope
[14:37:23] <Zash> No wildcard matching there.
[14:37:59] <Zash> And I doubt that* is a valid DNS label.
[14:38:15] <Asterix> so 2 errors in the cert ;)
[14:39:38] * naw left the chat.
[14:39:57] <Zash> This dump http://q.zash.se/bf032dc3.txt (scroll down) says there's two of each
[14:40:06] <Zash> one *.j.o and one j.o
[14:40:26] <Zash> so whichever should match
[14:40:50] <Asterix> yes, it will match with j.o, but *.j.o should not be there
[15:01:56] * Tobias left the chat.
[15:02:43] * Tobias joined the chat.
[15:04:36] <Florob> actually I think that's valid
[15:04:44] <Florob> http://tools.ietf.org/html/rfc6125#section-6.4.3
[15:10:44] <Zash> Valid for which 'that'?
[15:12:06] <Florob> Well, (while it's not encouraged) the identifier portion can be a wildcard domain name. I.e. dNSName and XmppAddr can be *.j.o and SRV can be xmpp-client.*.j.o
[15:15:23] <Asterix> ok, thanks I fix my code then
[15:17:31] <Zash> I'd prefer xmppaddr to not have wildcards, but then, srvnames are better for servers anyways, and client certs with whildcards would just be crazy :)
[15:18:24] <Florob> Well, XmppAddr is deprecated anyway
[15:19:14] <Zash> Heh, yeah, sorta, but is there a replacement?
[15:19:39] <Florob> I don't see how it's any different from SRV-ID functionally.
[15:19:44] <Florob> In fact SRV-ID is more specific
[15:20:01] <Zash> For server certs, yes, but for clients?
[15:20:19] <Florob> For clients it's still XmppAddr.
[15:20:34] <Florob> But that's not what we're discussing. Clients rarely check client certs ;)
[15:21:29] <Zash> :)
[15:21:36] <Florob> And for client usage is MUST be a JID. That doesn't have wildcards
[15:23:53] * Hermitifier joined the chat.
[16:25:37] * scippio joined the chat.
[16:42:09] * Florob left the chat.
[16:42:10] * Florob joined the chat.
[17:11:58] * harrykar left the chat.
[17:35:06] * Vincent V. joined the chat.
[17:40:22] * Zash left the chat.
[17:44:56] * Tobias left the chat.
[17:49:54] * harrykar joined the chat.
[18:16:04] * xnyhps joined the chat.
[18:43:51] * Tobias joined the chat.
[18:57:23] * darkrain left the chat.
[18:57:38] * darkrain joined the chat.
[19:06:35] * naw joined the chat.
[19:23:21] * Vincent V. left the chat.
[19:23:55] * Vincent V. joined the chat.
[19:29:58] * guus joined the chat.
[19:53:27] * xnyhps left the chat.
[20:58:54] * Vincent V. left the chat.
[21:00:45] * Vincent V. joined the chat.
[21:16:03] * jameschurchman joined the chat.
[21:16:45] * jameschurchman left the chat.
[22:05:51] * Asterix left the chat.
[22:07:00] * darkrain left the chat.
[22:24:09] * guus left the chat.
[22:57:29] * scippio left the chat.
[22:57:40] * scippio joined the chat.
[22:59:18] * naw left the chat.
[23:19:02] * Florob left the chat.
[23:50:48] * Tobias left the chat.