1

I've come across a couple issues now with various vendor products where connections to https://example.foo is handled differently from connections to https://ExAmPlE.FoO with the latter sometimes resulting in errors.

Is there a clear stance in the TLS standard for if applications should care?

AFAIK, it shouldn't matter and both should be treated the same. After all, isn't this essentially what web users do all the time? It's not like a user typing https://www.GoOgLe.cOM won't actually get to google...

Mike B
  • 3,336
  • 4
  • 29
  • 39
  • You should take into consideration that every Latin character has it's Unicode equivalent. For example, the Russian Cyrillic `A`, is interpreted differently than, but looks the same as a latin capital `A`. It's bytecode is different, but it's 'human' code is the same. This could result in phishing mails leading to Amazon.com, while not being the real Amazon. – Nomad Jun 04 '18 at 16:19

1 Answers1

2

Short answer: the hostname part/CN is case insensitive. The issue is not with TLS standards, but with the way other things are implemented, e.g. web server configuration, vendor-specific implementations, etc.

Long answer:

RFC 4343 clarifies that hostnames are case insensitive (RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification), see Section 6 Security Considerations. The section states cases where capitalization may have security impact, so the CANONICAL form of domain names must be used (as is the case with common names (CN) in digital certificates). In general the domain part of your URL should not be case sensitive. The rest is case sensitive, e.g. the full URI is definitely cases sensitive.

Also, see RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, section 2.7.3, which explains that the protocol specifier (http or https) and the hostname are case insensitive. This is confirmed by RFC5890, Section 2.3.2.4, where the actual algorithm to comparing hostnames is defined.

International domain names generally follow this (although via UNICODE transformations, as defined in RFC3454 and RFC3491).

The only possible explanation for the behavior exhibited is that it is possible that web server configuration may be case sensitive (e.g. the Virtual Host definition), or it is possible that something wasn't implemented exactly as defined in the standard by a vendor (won't be the first time, and won't be the last).

In a nutshell, the issue has nothing to do with the TLS and Internet standards, but with other factors.

I hope this helps!

Milen
  • 1,148
  • 6
  • 12