----- Original Message ----- > From: "Jimmy Hess" <mysi...@gmail.com>
> By the time the hostname is sent over HTTP, the SSL connection is > already established, and all the SSL negotiation already happened.. Correct, and yes, I did already know that (though, this morning, before coffee, it would have been hard to tell for sure :-). > it's up to the client to validate the server's FQDN matches the CN of > the certificate, or an alternative DNS name; which are all are > (hopefully) or ought to be, by definition FQDNs, before the server > knows what hostname(s) HTTP requests will be made against. Also correct. Our issue on point is this: that match where we supply an FQDN is performed by *some piece of code*, which knows that there are multiple names against which to match. What does that code do with a hostname string which is terminated by a period (it apparently does not treat it specially, and just attempts to match with it included, from Brian's experience) and... Is that the proper behavior? > If the domain in a certificate were not interpreted as a FQDN by the > client, this would mean, that the certificate for > CN=bigbank.example.com > might be used to authenticate a connection to > https://bigbank.example.com > which do the local resolver search order, is in fact a DNS lookup of > bigbank.example.com.intranet.example.com Sure: you can't match a supplied server domain name against cert names which are *longer* (have more atoms) than it is; I get that, see why, and approve. > Which might be captured by a Wildcard A record for *.com found in > the intranet.example.com. zone and pointed to a server > containing a phishing attack against bigbank.example.com; with a > DNS cache poisoned by a false negative cache NXDOMAIN entry for > bigbank.example.com. As is mentioned in RFC 1535, which Mark chastised me for accidentally mentioning a couple hours ago; yes. :-) Oh wait; no, this is a different *class* of attack, no? I can't *have* a wildcard for *.com, *because my resolvers won't ask my servers for that; they'll ask the root*; or do I need to finish reading 1535? > The exeption to not sending the domain name before encryption, would > be the shiny new TLS protocol version with the server supporting the > rarely used SNI extension; extension for server name indication, > that will one day allow virtual hosting for TLS protected HTTP > transport, sharing one IP address, with a different X509 certificate > served up by the server, based on which hostname has been requested > (once browsers and servers begin to support TLS1.2 as a replacement > for SSL); in this case, the crypto stack on the server does gain > access to the hostname. Wow; we *really* don't want to implement IPv6, do we? :-) > It probably doesn't matter if the server removes the "." or not, > before sending it.. the server has to allow the dot. It's not a question of what the server does; the server returns a Server Certificate packet, which the client library either matches on itself, or hands upstairs to ... something else. One of those two things makes the comparison, and our question is: Should that thing trim a trailing dot *off the local string*, before matching the names that came in in the cert. If my assertion from this morning, that names are automatically "absolute" in 1035 terms -- that is, a domain name with a dot after is equal to one without -- *everywhere except* 1) in a resolver query (where they're a hint to the resolver, and *don't* go out with the dot over the wire -- at leastI think they don't; I have to double check... and 2) inside a zone file, where they're a hint to the *server* about where to root the record; against $ORIGIN or not... is true, then the behavior I suggest for opening an SSL/TLS connection should also hold: strip the dot before you match, then match absolutely. > The HTTP/1.1 does mention something about HTTP proxies possibly > being able to handle a hostname that is not a FQDN, solely by > appending their own domain to the hostname; appending a suffix to the > hostname is allowed, in that specific case, but a FQDN must not be > changed. > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 > " > The use of IP addresses in URLs SHOULD be avoided whenever possible > (see RFC 1900 [24]). If the abs_path is not present in the URL, it > MUST be given as "/" when used as a Request-URI for a resource > (section 5.1.2). If a proxy receives a host name which is not a fully > qualified domain name, it MAY add its domain to the host name it > received. If a proxy receives a fully qualified domain name, the proxy > MUST NOT change the host name. > " Hmmm. I don't know that that applies here; we're strictly HTTPS; can you proxy that? Even if you could, the thing you need to look at is inside the encrypted channel, I think. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
