Hi Daniel, > Yes, I agree with that interpretation. Here's the paragraph from RFC3546: > > "HostName" contains the fully qualified DNS hostname of the server, > as understood by the client. The hostname is represented as a byte > string using UTF-8 encoding [UTF8], without a trailing dot.
exactly, this was the paragraph I was thinking about (and even cited in my first mail about this issue). > You interested in taking a shot at a patch for this problem? It seems like > it may be a good idea to simply normalize (strip trailing dots) at a central > early point in time. While I agree with the idea of normalizing the domain name as a first step, we need to take the higher level protocols into consideration. Every protocol on top of TLS can cause problems. Considering HTTP let us look into RFC 2616 section 3.2.2 [0]: 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. I am not exactly sure how the interplay between proxies and HTTP(S) traffic is specified but my point is that the hostname (the user supplied to the application) must not be modified when it travels up the layers. When we provide the URL 'https://www.google.com.' the TLS layer needs to do its normalization (as required per RFC 3556) and send out 'www.google.com' in the SNI part of the communication, however on the HTTP layer is has to stay the same. Even worse, a proxy would be allowed to modify it like adding the search domain (resulting in a HTTP hostname like 'www.google.com.local.') if the domain was not fully qualified. I have not checked the RFCs of IMAP and SMTP yet, but probably similar observations can be made. Hence the normalization would be less central but more very specific to SNI. Since I am not too familiar with the standards and implementations I could be wrong. The proxy case might not be relevant in the context of TLS, since it should never be able to modify the tunneled content. However some companies use transparent proxies which also decrypt outgoing traffic basically playing MITM all day (since all the clients have a custom root CA installed), but then again the RFC was probably not refering to this scenario. The host name in HTTP is also relevant for HTTP cookies even higher up the layer stack. This corners of the web stack lack some specification coverage, so we should probably decide what would be best to fill the gaps. Regards, Leon [0] http://tools.ietf.org/html/rfc2616#section-3.2.2 ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
