10 ms·

Some religious nuts are preventing me to visit Wikipedia. I use encrypted DNS to protect myself from man in middle attack, and it helps. But then they intercept

Some religious nuts are preventing me to visit Wikipedia. I use encrypted DNS to protect myself from man in middle attack, and it helps. But then they intercept certificate's name and drop the connection. So, thus this mean that TLS 1.3 will prevent sniffing certificate's name? And there won't be any certificate fingerprint on the wire to be sniffed, right?

blattimwind 9y ago
Active MITM remains able to sniff certificates, because the certificate is exchanged (indeed, must be exchanged) before you can authenticate the key exchange and thus lock out AMITM attackers.
- vbezhenar 9y ago
  Is it possible to launch active MITM attack and then establish connection like it wasn't there? The point of sniffing certificate is to block access for some websites and allow for others, located on the same IP address. Otherwise you could just block IP.
tialaramex 9y ago
Under TLS 1.3 the Server Name Indication extension becomes mandatory, so your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to [SNI is there to make "virtual hosting" possible for HTTPS, which is why you can get working SSL on a cheap bulk host without paying them extra for a dedicated IP address] So, a middlebox might choose to drop connections based on the name your client sends (and of course it could also choose to drop them based on the destination IP address, the amount of traffic you've sent recently, or the phase of the moon). But the certificate itself is now always encrypted, so the middlebox can't snoop that without acting as a proxy. It sounds as though you've (perhaps against your will) accepted the proxy, so in that case all bets are off anyway, a proxy can do whatever it likes, if you don't want that don't trust proxies.
- derefr 9y ago
  > Under TLS 1.3 the Server Name Indication extension becomes mandatory Is the client allowed to not send an SNI? If not, does this mean that HTTPS servers will no longer have a "default" HTTPS virtual host if accepting only TLSv1.3 connections? If you don't get to know anything about the backend at an IP until you've essentially proven you have a shared secret (the domain name), this could be a bad time for the folks who try to scan IP address space for HTTPS sites (e.g. the DDoSers who want to de-anonymize Cloudflare-protected backends in order to attack them directly.)
  - tialaramex 9y ago
    The SNI extension is a MUST in the TLS 1.3 standard. Of course this is not a law of physics, it's perfectly possible to implement a client which doesn't send this extension but the standard says to do this, so implementations which reject your connection for being non-standard might exist, might even become popular. You can reject connections that lack SNI even today if you want, it's just that the most popular web server software has the "default" behaviour you described, but that's not mandatory or unavoidable. Anyway, it is unlikely that TLS 1.3 will be popular enough to reject TLS 1.2 connections in the next say, five years unless there's some monumental security problem that makes TLS 1.2 moot.
    - derefr 9y ago
      > Anyway, it is unlikely that TLS 1.3 will be popular enough to reject TLS 1.2 connections in the next say Sure, most servers won't be able to take advantage of this. But if your server is using TLS only to speak to your reverse-proxy over the public Internet (e.g. if you're operating a Cloudflare-protected site where the TLS is terminated at Cloudflare and then a separate TLS connection is made from Cloudflare to your backend), you might be able to take full advantage of this as soon as your reverse-proxy's client logic supports TLSv1.3.
    - bscphil 9y ago
      So if middleware can just snoop the SNI and filter (e.g. Wikipedia) on that, doesn't that negate any of the supposed privacy improvements of TLS 1.3? Other people in this thread seem to think that it provides more protection against MITM and snooping from middleware than did 1.2. How is that supposed to work?
vbezhenar 9y ago
Why intercept certificate if you can block IP?
- darkhorn 9y ago
  Because Wikipedia has many IPs and they change from time to time. And best part is when Russians were blocking a blogger's web site based on IP he switched his IP to a bank's web site and thus the bank's IP was blocked automatically :)
  - raarts 9y ago
    Sounds strange that a bank would host its website on a shared Ip address.
    - duskwuff 9y ago
      They didn't. To clarify: the blogger set his domain to point to the bank's IP address. The automated domain blocking system resolved his domain and blocked "its IP" without confirming that the IP actually belonged to the targeted site.
      - zarex 9y ago
        That's absolutely glorious.
    - deleted 9y ago
      [deleted]
- acdha 9y ago
  IPs are often used by many sites: it’s like telling the post office to drop mail to 1234 5th St when that’s an apartment building with hundreds of residents. If you block a major CDN you’ll take out things like Microsoft, Apple, etc. and generate a lot more publicity for your censorship program.

blattimwind 9y ago

Active MITM remains able to sniff certificates, because the certificate is exchanged (indeed, must be exchanged) before you can authenticate the key exchange and thus lock out AMITM attackers.

vbezhenar 9y ago
Is it possible to launch active MITM attack and then establish connection like it wasn't there? The point of sniffing certificate is to block access for some websites and allow for others, located on the same IP address. Otherwise you could just block IP.

tialaramex 9y ago

Under TLS 1.3 the Server Name Indication extension becomes mandatory, so your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to [SNI is there to make "virtual hosting" possible for HTTPS, which is why you can get working SSL on a cheap bulk host without paying them extra for a dedicated IP address] So, a middlebox might choose to drop connections based on the name your client sends (and of course it could also choose to drop them based on the destination IP address, the amount of traffic you've sent recently, or the phase of the moon). But the certificate itself is now always encrypted, so the middlebox can't snoop that without acting as a proxy. It sounds as though you've (perhaps against your will) accepted the proxy, so in that case all bets are off anyway, a proxy can do whatever it likes, if you don't want that don't trust proxies.

derefr 9y ago
> Under TLS 1.3 the Server Name Indication extension becomes mandatory Is the client allowed to not send an SNI? If not, does this mean that HTTPS servers will no longer have a "default" HTTPS virtual host if accepting only TLSv1.3 connections? If you don't get to know anything about the backend at an IP until you've essentially proven you have a shared secret (the domain name), this could be a bad time for the folks who try to scan IP address space for HTTPS sites (e.g. the DDoSers who want to de-anonymize Cloudflare-protected backends in order to attack them directly.)
- tialaramex 9y ago
  The SNI extension is a MUST in the TLS 1.3 standard. Of course this is not a law of physics, it's perfectly possible to implement a client which doesn't send this extension but the standard says to do this, so implementations which reject your connection for being non-standard might exist, might even become popular. You can reject connections that lack SNI even today if you want, it's just that the most popular web server software has the "default" behaviour you described, but that's not mandatory or unavoidable. Anyway, it is unlikely that TLS 1.3 will be popular enough to reject TLS 1.2 connections in the next say, five years unless there's some monumental security problem that makes TLS 1.2 moot.
  - derefr 9y ago
    > Anyway, it is unlikely that TLS 1.3 will be popular enough to reject TLS 1.2 connections in the next say Sure, most servers won't be able to take advantage of this. But if your server is using TLS only to speak to your reverse-proxy over the public Internet (e.g. if you're operating a Cloudflare-protected site where the TLS is terminated at Cloudflare and then a separate TLS connection is made from Cloudflare to your backend), you might be able to take full advantage of this as soon as your reverse-proxy's client logic supports TLSv1.3.
  - bscphil 9y ago
    So if middleware can just snoop the SNI and filter (e.g. Wikipedia) on that, doesn't that negate any of the supposed privacy improvements of TLS 1.3? Other people in this thread seem to think that it provides more protection against MITM and snooping from middleware than did 1.2. How is that supposed to work?

vbezhenar 9y ago

Why intercept certificate if you can block IP?

darkhorn 9y ago
Because Wikipedia has many IPs and they change from time to time. And best part is when Russians were blocking a blogger's web site based on IP he switched his IP to a bank's web site and thus the bank's IP was blocked automatically :)
- raarts 9y ago
  Sounds strange that a bank would host its website on a shared Ip address.
  - duskwuff 9y ago
    They didn't. To clarify: the blogger set his domain to point to the bank's IP address. The automated domain blocking system resolved his domain and blocked "its IP" without confirming that the IP actually belonged to the targeted site.
    - zarex 9y ago
      That's absolutely glorious.
  - deleted 9y ago
    [deleted]
acdha 9y ago
IPs are often used by many sites: it’s like telling the post office to drop mail to 1234 5th St when that’s an apartment building with hundreds of residents. If you block a major CDN you’ll take out things like Microsoft, Apple, etc. and generate a lot more publicity for your censorship program.