Bill Janssen <[EMAIL PROTECTED]> added the comment: Sorry to be so brief there -- I was off on vacation.
Verifying hostnames is a prescription that someone (well, OK, Eric Rescorla, who knows what he's talking about) put in the https IETF RFC (which, by the way, is only an informational RFC, not standards-track). It's a good idea if you're a customer trying to talk to Wells-Fargo, say, over an https connection, but isn't suitable for all https traffic. I support putting it in the httplib Https class by default, but there should be a way to override it, as there is with the Java APIs for https connections. (Take a look at javax.net.ssl.HostnameVerifier; one of the more popular Java classes at PARC is a version of this that verifies any hostname). So what's wrong with it? There are two problems. The first is that certificates for services are all about the hostname, and that's just wrong. You should verify the specific service, not just the hostname. So a client that really cares about what they are talking to should have the certificate for that service, and verify that it is the service it's talking to, and ignore the hostname in the URL. But the larger problem is that hostnames are a DNS construct for humans, and not really well supported on computers, or by the services that run on those computers. Most computers have only the haziest notion of what their hostname is, and many have lots of different hostnames (my laptop has at least five hostnames that I know of, all meaning the same computer, but with five different PARC IP addresses). So the services running on that computer aren't real clear about their hostnames, either. If I run a service on that computer that I secure with SSL, so that packets going over my WiFi are encrypted, which hostname should that service declare itself to be in the certificate? And the services on that computer keep running, even when it switches its IP address (and thus its set of hostnames). So doing hostname matching provokes lots of false negatives, especially when it's not needed. I think it by and large isn't a good idea, though I support having it (in an overrideable form) for the client-side https class in httplib. This is all exacerbated by the fact that HTTP isn't what it was when Eric wrote that RFC eight years ago. The growth of Web 2.0 and "RESTful" services means that lots of new things are using https in a much less formal way, more to get encrypted packets than to verify endpoints. So false negatives caused by mindless hostname verification cause real damage. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com