[HN Gopher] Implementing TLS Encrypted Client Hello [Nov 2021]
       ___________________________________________________________________
        
       Implementing TLS Encrypted Client Hello [Nov 2021]
        
       Author : xrisk
       Score  : 27 points
       Date   : 2021-12-12 16:15 UTC (6 hours ago)
        
 (HTM) web link (guardianproject.info)
 (TXT) w3m dump (guardianproject.info)
        
       | [deleted]
        
       | kingcharles wrote:
       | So, to summarize, one of the remaining issues on the Web is that
       | when you browse to an HTTPS site the name of the site you are
       | connecting to is still in cleartext. The reason for this is that
       | you regularly have 1 IP address with multiple Web sites on it.
       | The server needs to know which Web site to forward your request
       | to. Once it has forwarded your request the SSL cert of that site
       | takes over and all future requests are encrypted.
       | 
       | Encrypted Client Hello would install a server-wide certificate
       | that would encrypt the data from the first connection so that the
       | handshake wouldn't be visible to the outside.
       | 
       | The best a MITM could do is determine that you are connecting to
       | a specific IP but would not be able to determine which site on
       | that IP you are browsing.
        
         | infotogivenm wrote:
         | DNS is still a thing but there are at least decent widely
         | deployed solutions.
        
           | tkot wrote:
           | And the two most popular ways to encrypt DNS queries rely on
           | TLS (DNS over TLS and DNS over HTTPS).
        
       | LinuxBender wrote:
       | I am looking forward to this being supported officially in the
       | mentioned daemons. The authors should also work with Qualys
       | [1a][1b] _development site_ and open source developers [2] that
       | test TLS configurations to add additional tests early on.
       | 
       | [1a] - https://www.ssllabs.com/ssltest/
       | 
       | [1b] - https://dev.ssllabs.com/ssltest/
       | 
       | [2] - https://github.com/drwetter/testssl.sh.git
        
       | captn3m0 wrote:
       | Am I correct in assuming that this is going to be mostly
       | impactful on the server side for at-risk services that are at
       | risk of getting blocked using SNI fingerprinting?
       | 
       | Since browsers will get adoption easily, but servers will need to
       | make changes, wondering which operators will have the right
       | incentives to upgrade to ECH, especially since it's much more
       | involved than usual TLS upgrades.
        
         | tialaramex wrote:
         | As with TLS 1.3 itself, a big benefit is that the Inner
         | encrypted Hello can't be inspected by whatever (inevitably
         | poorly made and never updated) middleboxes are on the route
         | between client and server.
         | 
         | It isn't important to the Internet whether these middle boxes
         | are put there by the Government of the People's Republic of
         | China to promote Harmony, by your daughters $1000 per month
         | private school to prevent her looking at "inappropriate"
         | material (whether that's the 1619 project, TikTok, or porn) or
         | your employer to dissuade employees from uploading PDFs of
         | company secrets, the problem and the solution is the same from
         | the Internet's point of view.
         | 
         | Did you know that TLS certificate compression is an obvious,
         | trivial improvement to the rapidity of secured connections that
         | _could not be deployed_ for over a decade because until TLS 1.3
         | the Certificate message is cleartext and so if you send one
         | that looks  "wrong" to some dodgy middlebox firmware written in
         | 2006 your web site doesn't work?
         | 
         | Whenever the purpose of bypassing middleboxes is explained,
         | there are people who are outraged. How dare we fix the
         | Internet? They were relying on FaultySoft CrapSecurity 0.0.1
         | from 2006 and now we've ruined everything by bypassing it. No
         | we didn't, by definition if what we did worked, your middlebox
         | already wasn't protecting you. We've shattered your illusion
         | and that's all. Santa Claus isn't real either.
        
         | jeroenhd wrote:
         | The incentive could be as simple as ssllabs not handing out an
         | A or A+ score if your site doesn't support encrypted hello.
         | I've heard of several huge companies that base the security
         | rating of their websites in part in getting a good score on the
         | ssllabs test, so they and their vendors would need to move once
         | the test changes.
         | 
         | I don't think it's healthy to rely on an arbitrary test like
         | that for your company contracts, but it's what's happening.
         | Once the feature is stable in server and client software, I'm
         | sure it'll become part of the test and many big companies with
         | complicated contracts will rush to implement it.
         | 
         | There are some companies that I expect will be early adopters,
         | namely companies that are sensitive in nature. Porn, specific
         | medical websites, you name it. With proxied DoH and encrypted
         | SNI you can set up a connection to a website privately and
         | securely without ever naming it in plain text. If that website
         | runs behind a big cloud host like Cloudflare, there's no way
         | for your ISP or any other passively spying company to know what
         | you're up to.
        
       ___________________________________________________________________
       (page generated 2021-12-12 23:01 UTC)