Mixed case XML ID and Routing Name results in failed TLS handshake

Behavior Seen: When an HTTPS delivery service is created with a mixed case XML ID and/or mixed case Routing Name, the SNI sent by a client appears to cause Apache Traffic Server to respond with an empty X509 server certificate chain. DNS A/AAAA records are considered to be case insensitive via RFC4343. TLS Extension Server Name Indication (SNI) is also supposed to be case insensitive, but RFC 4366 and RFC 6066 seem to be in contradiction with respect to proper SNI string matching (case sensitive vs. case-insensitive).

Possible Solution: Delivery Service XML ID and Routing Name should only contain lowercase alpha characters due to the ambiguity of how SNI is sent by HTTPS/TLS clients and the comparison algorithm used by HTTPS servers to process an SNI match.

Impacted Components: Apache Traffic Server - Delivery services in DNS routing mode appear to be impacted by this bug when the SNI is sent directly to the edge cache. No X509 certificate chain is sent unless the SNI matches the original remap/hostname exactly (comparison algorithm appears to be incorrectly case-sensitive).

Example Request using original mixed case Delivery Service URL:

$ curl -o /dev/null -Lvs https://edge.DeMo1.mycdn.ciab.test

* About to connect() to video.DeMo1.mycdn.ciab.test port 80 (#0)
*   Trying 172.21.0.8...
* Connected to video.DeMo1.mycdn.ciab.test (172.21.0.8) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: video.DeMo1.mycdn.ciab.test
> Accept: */*
> 
< HTTP/1.1 302 Found
< Location: http://edge.DeMo1.mycdn.ciab.test/
< Content-Length: 0
< Date: Wed, 16 Jan 2019 23:34:01 GMT
< 
* Connection #0 to host video.DeMo1.mycdn.ciab.test left intact
* Issue another request to this URL: 'http://edge.DeMo1.mycdn.ciab.test/'
* About to connect() to edge.DeMo1.mycdn.ciab.test port 80 (#1)
*   Trying 172.21.0.12...
* Connected to edge.DeMo1.mycdn.ciab.test (172.21.0.12) port 80 (#1)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: edge.DeMo1.mycdn.ciab.test
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html
< Accept-Ranges: bytes
< ETag: "3812539862"
< Last-Modified: Thu, 10 Jan 2019 22:53:33 GMT
< Cache-Control: public, max-age=300
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: Accept, Origin, Content-Type
< Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
< Content-Length: 1881
< Date: Wed, 16 Jan 2019 23:34:01 GMT
< Server: ATS/7.1.4
< Age: 2
< Via: http/1.1 mid.infra.ciab.test (ApacheTrafficServer/7.1.4 [uScMsSfWpSeN:t cCMi p sS]), http/1.1 edge.infra.ciab.test (ApacheTrafficServer/7.1.4 [uScMsSfWpSeN:t cCMi pSs ])
< Connection: keep-alive
< 
{ [data not shown]
* Connection #1 to host edge.DeMo1.mycdn.ciab.test left intact

Example Request with a fully lowercased URL:

$ curl -o /dev/null -vs https://edge.demo1.mycdn.ciab.test/

* About to connect() to edge.demo1.mycdn.ciab.test port 443 (#0)
*   Trying 172.21.0.8...
* Connected to edge.demo1.mycdn.ciab.test (172.21.0.8) port 443 (#0)
* TCP_NODELAY set
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/etc/openssl/cert.pem
  CApath: /usr/local/etc/openssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Unknown (21):
* TLSv1.2 (IN), TLS alert, handshake failure (552):
* error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
* Closing connection 0

[shinrich]

TrafficServer does try putting the SNI to lower case before doing the lookup. However, I assume that we store the names as cased in the certificates. We should probably just always do a case-insensitive lookup. And it doesn't look we do the lower-casing for the wildcard check.

So to be clear, your issue would be solved, if the certificate lookup was case insensitive?

@shinrich Yes, I believe a case-insensitive lookup would fix this issue. The Traffic Router, Apache HTTPD, and Nginx all seem to 1) lowercase the SNI and the certificate names (CN and any number of SANs present) before a strncmp() or 2) simply skip the lowercase step and use something like strncasecmp() for the comparison. Given that DNS A/AAAA/CNAME... records are case-insensitive, it would follow that SNI lookups against certificate names in a CN/SANs should be case insensitive as well (including wildcard certificates).

[jhg03a]

I worked with @JBevillC on this and can verify his error case. ATS isn't the only caching server that seems to have this issue: curl/curl#780 .

This issue has been fixed by PR(s): #3380, #3382, and #3331.

Issue will be closed.