(Discussion) Should we be able to disable HTTP/3, TLS/1.3 and QUIC (& potentially by default)?

Metrokoto commented 3 weeks ago

Preliminary checklist

[X] I have read the README
[X] I have searched existing issues for my feature request. This is a new issue (NOT a duplicate) and is not related to another issue.
[X] I have searched wont fix issues and this request is not among them
[X] This is a feature request for the Cromite browser; not the website nor F-Droid nor anything else.

Is your feature request related to privacy?

Yes

Is there a patch available for this feature somewhere?

No

Describe the solution you would like

Now, I am going to probably sound like a conspiracy theorist, but please hear my concerns before you make any judgements.

The three key talking points I am going to discuss are:

The experimental nature of HTTP/3, TLS/1.3 and QUIC
Google's involvement
The potential implications of all this

So first off, let me get something out of the way. TLS/1.3 only launched around six years ago, and HTTP/3 similarly so. HTTP/3 itself has been dubbed a "revolutionary" technology, as has TLS/1.3, despite not having stood the test of time, unlike HTTP/2 and TLS/1.2, and both continue to be marked as experimental by most browsers, including in Chromium (see #enable-quic), which raises questions about the potential for issues to arise, not only from a security perspective but a privacy perspective as well.

Secondly, the usage proposed by Cromite is for privacy, is it not? So why would we continue to allow such experimental technologies to be enabled by default, especially considering Google's heavy invested interest in said technologies? Just to warn you, I am going to get a bit conspiracy theorist now, but; I personally question whether Google has mal-intent for creating QUIC, potentially to backdoor the encryption to harvest data by implementing non-auditable forks of QUIC on their own servers whilst the rest of the web uses the open source version.

I can personally see the argument for allowing TLS/1.3 by default, however the Early Data replay vulnerability brings into question it's long term stability and practicality, especially considering how it is still being added to, in stark contrast to TLS/1.2.

Lastly, I want to wrap this up by giving my final thoughts on what to do about this.

Personally, I think the best overall solution would be to disable any TLS 1.3 and QUIC related flags by default (as they tend to be marked experimental anyway), and have optional settings to re-enable them, OR, alternatively, leave them on, but make users aware of Google's influence on HTTP/3, and that it is experimental, and offer users a way to disable it in the privacy settings.

Describe alternatives you have considered

Blocking UDP/443 at the firewall, disabling #enable-quic

uazo commented 3 weeks ago

discussions at https://github.com/uazo/cromite/discussions please.

I don't rely on assumptions, if you have technical documents that prove your convience we can discuss it.

I can personally see the argument for allowing TLS/1.3 by default

TLS 1.3 has better handling in boringssl (which is the library used by chromium) because the order of encryption protocols is fixed and not tied to device characteristics.

however the Early Data replay vulnerability

TLS Zero RTT is disabled in cromite because TLS-resumption is disabled by default.

Metrokoto commented 3 weeks ago

I don't rely on assumptions, if you have technical documents that prove your convience we can discuss

I am glad you asked, here are various articles and resources on the topic I have read over the years:

http://www.csoonline.com/article/569541/6-ways-http-3-benefits-security-and-7-serious-concerns.html

http://pulse.internetsociety.org/blog/the-challenges-ahead-for-http-3

http://ably.com/topic/http-2-vs-http-3

http://www.reddit.com/r/cybersecurity/comments/w7134z/overview_and_security_implications_of_http3_and/

uazo commented 3 weeks ago

here are various articles and resources on the topic I have read over the years:

And where's the proof? read and verify them, you can't ask me to do that.

for example: from http://www.csoonline.com/article/569541/6-ways-http-3-benefits-security-and-7-serious-concerns.html:

0-RTT resumption vulnerabilities

already said

Connection ID manipulation attacks UDP amplification attack Stream exhaustion attack
Connection reset attack

is a server side problem, not a browser issue

QUIC version downgrade attack

see https://source.chromium.org/chromium/chromium/src/+/main:net/third_party/quiche/src/quiche/quic/core/crypto/crypto_utils.cc;l=591;drc=2d55fc7d93da4eb4aa604adc2b041a547f1281bd;bpv=1;bpt=1

I leave it to you to verify the other links.

uazo / cromite