Re: [Python-Dev] SSL certs
On 9/13/07, Bill Janssen [EMAIL PROTECTED] wrote: However, there is an alternative to using multiple IP addresses: one could also use multiple subject alternative names, and create a certificate that lists them all. Unfortunately, much of the client code that does the hostname verification is wrapped up in gullible Web browsers or Java HTTPS libraries that swallowed RFC 2818 whole, and not easily accessible by applications. Does any of it recognize and accept subject alternative name? For what it's worth, when I last looked at this (a year or so ago), only a few fringe browsers on mobile phones had issues with accepting our wildcard certificate, and some of those only because they didn't trust the root authority. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SSL certs
I guess something we should think about is whether to introduce RFC 2818 hostname checking into urllib.urlopen() and similar utilities. Presumably one would add an optional arg specifying a file full of root certs to validate against, and if that arg was present, would retrieve the hostname info from the validated cert, and do the client-side check. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SSL certs
My understanding is that the client tells the server which hostname it wants to use; the server should then pass down that information. That's how virtual hosting works in the first place. The only difference with SSL is that the hostname must have a unique IP address, so that when the client does a reverse DNS to validate the IP address presented by the SSL certificate, it all comes together correctly. Unfortunately, it does not quite work that way. The client tells the server what hostname to use only *after* the SSL connection has been established, and certificates being exchanged (in the Host: header). So the Host: header cannot be used for selecting what certificate to present to the client. *That* is the reason why people typically assume they have to have different IP addresses for different SSL hosts: certificate selection must be done based on IP address (which is already known before the SSL handshaking starts). There is no need for the client to do a reverse name lookup, and indeed, the client should *not* do a reverse DNS lookup to check the server's identity. Instead, it should check the host name it wants to talk to against the certificate. However, there is an alternative to using multiple IP addresses: one could also use multiple subject alternative names, and create a certificate that lists them all. There are, of course, wildcard certs; I don't understand how those work. The same way: the client does *not* perform a reverse name lookup. Instead, it just matches the hostname against the name in the certificate; if the certificate is for *.python.org (say) and the client wants to talk to pypi.python.org, it matches, and hostname verification passes. It would also pass if the client wanted to talk to cheeseshop.python.org, or wiki.python.org (which all have the same IP address). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SSL certs
However, there is an alternative to using multiple IP addresses: one could also use multiple subject alternative names, and create a certificate that lists them all. Unfortunately, much of the client code that does the hostname verification is wrapped up in gullible Web browsers or Java HTTPS libraries that swallowed RFC 2818 whole, and not easily accessible by applications. Does any of it recognize and accept subject alternative name? It's possible to at least override the default Java client-side hostname verification handling in a new application. And Python is lucky; because there was no client-side hostname verification possible, RFC 2818 hasn't been plastered into the Python standard library :-). Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SSL certs
However, there is an alternative to using multiple IP addresses: one could also use multiple subject alternative names, and create a certificate that lists them all. Unfortunately, much of the client code that does the hostname verification is wrapped up in gullible Web browsers or Java HTTPS libraries that swallowed RFC 2818 whole, and not easily accessible by applications. Does any of it recognize and accept subject alternative name? Works fine with Firefox and MSIE. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SSL certs
On Wed, Sep 12, 2007, Bill Janssen wrote: By the way, I think the hostname matching provisions of 2818 (which is, after all, only an informational RFC, not a standard) are poorly thought out. Many machines have more hostnames than you can shake a stick at, and often provide certs with the wrong hostname in them (usually because they have no way to determine what the *right* hostname is, from inside that machine). ...which is why you pretty much need to have a canonical hostname mapped to each IP you're using on a machine. Basically, you need to map the hostname you intend to use to an IP, then do reverse-DNS to find out whether the hostname is in fact the canonical hostname. If not, you're using the wrong hostname on your cert. Yep. The problem is having a particular service know which certificate it should choose to use, and also to know when the network connectivity has changed. Usually, server ports are bound to wildcard IP addresses, so that they can still be reached even if the network connectivity changes (particularly true for servers running on laptops, or the Python server I'm running on my iPhone). The server has no way of knowing which IP address the client knows it as, and no way of knowing which of its multiple certificates to present, so that the name in the cert will match the name the client thought it was using. My understanding is that the client tells the server which hostname it wants to use; the server should then pass down that information. That's how virtual hosting works in the first place. The only difference with SSL is that the hostname must have a unique IP address, so that when the client does a reverse DNS to validate the IP address presented by the SSL certificate, it all comes together correctly. There are, of course, wildcard certs; I don't understand how those work. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important. --Henry Spencer http://www.lysator.liu.se/c/ten-commandments.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
