3 ms·

Title: Default, unchangeable1 browser settings and modern, unencrypted SNI 1 Ignoring the possibility of editing and recompiling the source code, if the browse

Title: Default, unchangeable1 browser settings and modern, unencrypted SNI 1 Ignoring the possibility of editing and recompiling the source code, if the browser is open source. Background SNI is only required for websites using TLS that are also using shared IP address space (e.g., CDNs) where a single IP address may be used by multiple websites, perhaps having no common owner or no relationship to each other. However websites that have rented or purchased a dedicated IP address do not need to use SNI in order to take advantage of TLS. Traditionally, all websites using SSL/TLS fell into this category. It is possible many websites using TLS still use dedicated IP addresses and hence do not need SNI. For the curious, some data on websites posted to HN is provided below. By default popular browsers send unencrypted SNI regardless of whether the website is using a shared IP address and regardless of whether the website actually requires SNI. This default, unchangeable setting makes sense if one assumes that, by and large, most websites using TLS are also sharing an IP address with other websites. The question is whether that assumption is true. Hence we ask: What percentage of the websites does the HN reader visit that are both (a) using TLS and (b) using a shared IP address. In other words, what percentage of these websites accessed by HN readers actually require SNI to be sent by the browser? Sample data: A survey of websites currently appearing on HN Number of unique urls: 462 Number of http urls: 72 (unique domains: 67) Number of https urls: 390 (unique domains: 229) Number of https urls requiring SNI: 36 Number of https urls requiring correct SNI: 22 What is meant by "correct SNI"? It is possible with some CDNs to send incorrect SNI and still retrieve the correct page. This is because these CDNs do not use the SNI in order to retrieve the correct page. Like all other sites since the dawn of the web (up until the appearance of SNI) they only need a correct Host header. (This begs the question of what, if anything, the SNI might be used for within these CDNs. Users concerned about privacy, tracking, ads, etc. might wonder if the SNI is being used for something.) Sending an incorrect (fake) SNI has been nicknamed "domain fronting". The user simply picks any domain using the CDN and sends it as the "fake" SNI. 14 of the 36 are using a CDN that does not require a correct SNI in order to retrieve the correct page. I have automated this "SNI test" and can run it daily, weekly or, for a larger sample, I can run it on historical HN data, e.g., all domains appearing on HN in the year XXXX. Is anyone aware of formal studies on the percentage of sites that actually require (correct) SNI?

caf 8y ago
This begs the question of what, if anything, the SNI might be used for within these CDNs. They are using it to choose the certificate that is provided to the client.
- textmode 8y ago
  Is there any technical (cf. practical) reason the client must obtain the certificate from the server it names, and contemporaneous with the client's HTTP command? Is there any technical reason the client cannot obtain the certificate from other sources and/or not contemporaneously with the HTTP command? For example, CurveCP explains how the public key can be inserted into (DNSCurve-encrypted) DNS RRs. Clients can obtain the public keys from DNS servers instead of from www servers. They might even obtain public keys in bulk in zone files rather than by piecemeal requests. Further, CurveCP provides for a "server extension", an identifier that allows multiple sites to use the same IP address and port, obviating the problem which SNI aims to solve. For example, third party sources such as crt.sh provide repositories of certificates that users can download at a time they choose, not necessarily contemporaneous with when they send HTTP commands to the servers named in the certificates. There are a variety of sources of bulk certificates in addition to crt.sh. (Incidentally, crt.sh does not require SNI.) The practice of third parties providing certificates versus letting clients obtain them from the named servers/issuing parties is seen among the few companies/organizations that write popular clients when they distribute collections of "trusted" certificates with the client software. Another example is when a www server sends "intermediate certificates" along with the certificate that names the www server. This too demonstrates third party distribution of public keys to clients instead of letting clients get the keys from the entity to which they were issued.
  - caf 8y ago
    No matter how the client obtains the server certificate, it still has to somehow tell the server which server certificate it has used for the public key which it has encrypted the premaster secret with.
deleted 8y ago
[deleted]

caf 8y ago

This begs the question of what, if anything, the SNI might be used for within these CDNs. They are using it to choose the certificate that is provided to the client.

textmode 8y ago
Is there any technical (cf. practical) reason the client must obtain the certificate from the server it names, and contemporaneous with the client's HTTP command? Is there any technical reason the client cannot obtain the certificate from other sources and/or not contemporaneously with the HTTP command? For example, CurveCP explains how the public key can be inserted into (DNSCurve-encrypted) DNS RRs. Clients can obtain the public keys from DNS servers instead of from www servers. They might even obtain public keys in bulk in zone files rather than by piecemeal requests. Further, CurveCP provides for a "server extension", an identifier that allows multiple sites to use the same IP address and port, obviating the problem which SNI aims to solve. For example, third party sources such as crt.sh provide repositories of certificates that users can download at a time they choose, not necessarily contemporaneous with when they send HTTP commands to the servers named in the certificates. There are a variety of sources of bulk certificates in addition to crt.sh. (Incidentally, crt.sh does not require SNI.) The practice of third parties providing certificates versus letting clients obtain them from the named servers/issuing parties is seen among the few companies/organizations that write popular clients when they distribute collections of "trusted" certificates with the client software. Another example is when a www server sends "intermediate certificates" along with the certificate that names the www server. This too demonstrates third party distribution of public keys to clients instead of letting clients get the keys from the entity to which they were issued.
- caf 8y ago
  No matter how the client obtains the server certificate, it still has to somehow tell the server which server certificate it has used for the public key which it has encrypted the premaster secret with.

deleted 8y ago

[deleted]