3 ms·

> Before a client can create a CurveCP connection, it needs to know (1) the server's long-term public key and (2) the server's address That (1) seems wildly im

by sofixa 4y ago

> Before a client can create a CurveCP connection, it needs to know (1) the server's long-term public key and (2) the server's address That (1) seems wildly impractical? How would you distribute, securely, privately, anonymously and generally ( for the whole planet) the public keys? The only way i can think of is something like the HSTS preload lists which is quite centralised ( per browser), or DNS. Also it's IPv4 only, which is only kind of excusable for "last version 2011". I don't see a way around either SNI-like mechanism or a pre-shared key for hosting multiple sites on the same IP, unless everyone moves to IPv6 (which would still be annoying for web hosting, to have an IP per domain). Edit: > The client and server administrators don't meet secretly to share an encryption/authentication key. The server has a long-term public key S visible to everyone; the client uses this key S to encrypt data for the server and to verify data from the server So the wording is a bit unclear, the client needs to know the key, but the key is visible to everyone.

vbezhenar 4y ago
> or DNS That’s correct. ECH relies on DNS over HTTPS to retrieve server public key which is used to encrypt client hello message.
- sofixa 4y ago
  So the censor just needs to inspect the DNS over HTTPS' request's SNI and block that? Even easier for them, the blocklist is shorter.
  - vbezhenar 4y ago
    Well, if you're using something like 1.1.1.1 for your DoH, you don't really need to inspect SNI, I don't think that there're other domains on that IP address. Yes, blocking stuff is the ultimate way and you can't really deal with that. You can just block any ECH (former ESNI) traffic as well. Encrypting domain is a way to prevent someone learning things about your traffic. It's not a way to stop blocking. I'd say it's a way to provoke more blocking. It might sound strange, but to reduce blocking you should remove encryption altogether. Usually censors apply censorship on a specific web pages. So if you're browsing wikipedia without encryption, censors can block that specific article, but rest will be available to you. With encryption the entire wikipedia should be blocked just to restrict access to a single article. BTW you can remove encryption but keep authentication. TLS (at least previous versions) allowed for that. Theoretically it'd allow censors to apply their censorships, but it'd prevent them from changing content. I think that in the future people will think more about that concept.
    - dane-pgp 4y ago
      So you suggest that we give up all privacy (including the privacy of all our online passwords), and lose access to every page that a government censor might take issue to, just to prevent the hypothetical problem of the government over-blocking pages that it doesn't strictly need to? Actually I think that over-blocking would be good, as it would encourage more people to use Tor and VPNs, it would encourage more negative public opinion against the government spies/censors, and it would act as a form of economic sanctions against the regime because their citizens would get less value from the internet than they would without the over-blocking.
  - Ajedi32 4y ago
    Sure, but then you're blocking the user's DNS server, rendering the entire internet unusable for them, not just one specific site. That was always possible with or without deep packet inspection.
    - sofixa 4y ago
      Most DNS over HTTPS compatible clients would gracefully downgrade to regular DNS.
      - Ajedi32 4y ago
        Then most DNS-over-HTTPS clients are vulnerable to active attackers. That's the trade-off you make when falling back to an unsecured protocol. If clients aren't using some sort of encrypted DNS, then they're vulnerable to domain censorship anyway regardless of whether they're using QUIC.

by sofixa 4y ago

vbezhenar 4y ago

> or DNS That’s correct. ECH relies on DNS over HTTPS to retrieve server public key which is used to encrypt client hello message.

sofixa 4y ago
So the censor just needs to inspect the DNS over HTTPS' request's SNI and block that? Even easier for them, the blocklist is shorter.
- vbezhenar 4y ago
  Well, if you're using something like 1.1.1.1 for your DoH, you don't really need to inspect SNI, I don't think that there're other domains on that IP address. Yes, blocking stuff is the ultimate way and you can't really deal with that. You can just block any ECH (former ESNI) traffic as well. Encrypting domain is a way to prevent someone learning things about your traffic. It's not a way to stop blocking. I'd say it's a way to provoke more blocking. It might sound strange, but to reduce blocking you should remove encryption altogether. Usually censors apply censorship on a specific web pages. So if you're browsing wikipedia without encryption, censors can block that specific article, but rest will be available to you. With encryption the entire wikipedia should be blocked just to restrict access to a single article. BTW you can remove encryption but keep authentication. TLS (at least previous versions) allowed for that. Theoretically it'd allow censors to apply their censorships, but it'd prevent them from changing content. I think that in the future people will think more about that concept.
  - dane-pgp 4y ago
    So you suggest that we give up all privacy (including the privacy of all our online passwords), and lose access to every page that a government censor might take issue to, just to prevent the hypothetical problem of the government over-blocking pages that it doesn't strictly need to? Actually I think that over-blocking would be good, as it would encourage more people to use Tor and VPNs, it would encourage more negative public opinion against the government spies/censors, and it would act as a form of economic sanctions against the regime because their citizens would get less value from the internet than they would without the over-blocking.
- Ajedi32 4y ago
  Sure, but then you're blocking the user's DNS server, rendering the entire internet unusable for them, not just one specific site. That was always possible with or without deep packet inspection.
  - sofixa 4y ago
    Most DNS over HTTPS compatible clients would gracefully downgrade to regular DNS.
    - Ajedi32 4y ago
      Then most DNS-over-HTTPS clients are vulnerable to active attackers. That's the trade-off you make when falling back to an unsecured protocol. If clients aren't using some sort of encrypted DNS, then they're vulnerable to domain censorship anyway regardless of whether they're using QUIC.