1783791 - Optionally send no SNI for HTTPS alike connections (when using encrypted DNS)

Status: RESOLVED INVALID

(Core :: Networking, enhancement)

Description

[Master ? [:masterquestionable]]

See [ https://github.com/curl/curl/issues/9160#issuecomment-1189604667 ].
    Similar to the "HTTPS-Only Mode"'s implementation.

    Note: "-k" in `curl` means skip certificate verification.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

I don't think disabling SNI in certain situations would make things any better.
We are actively working on ECH support, which should improve the privacy situation there.

Comment 2

[Master ? [:masterquestionable]]

    The reasoning has been given in the linked post (in particular [ https://github.com/curl/curl/issues/9160#issuecomment-1188602124 ]).
    It appears helpful whatsoever.

Comment 3

[Master ? [:masterquestionable]]

    Refactored:
https://github.com/curl/curl/issues/9160#issuecomment-1188602124
[[
    "Doesn't sound like a topic for a curl issue nonetheless."
<^>    Indeed specifically not an issue for `curl` only.
    Seemingly applies to... all current implementations network related.

    “The SNI "leak" of the target host name is a long-standing known issue.”
<^>    Long-standing, known by few.
    "We don't need to deal with it here."
<^>    Perhaps we don't. But we may.
    "The solution for that is called ECH."
<^>    Yes, somewhat. But a critical issue of ECH is that requires both Client Server support.
    And as of yet ECH seems to have been only deployed on measly amount of sites. [ https://github.com/mozilla-mobile/fenix/issues/4584#issuecomment-1186094287 ]

    Meanwhile we may still optimize the flow of ECH support:
    |1| Attempt ECH if Server supports.
    |2| Send no SNI if Server doesn't support ECH (only when using encrypted DNS):
    |2.1| Server may actually return a valid result: success.
    |2.2| Server returns wrong certificate: prompt for using "-k" or "--leak-sni".
    |2.3| Server complains "Unrecognized Name" or whatsoever error: prompt for "--leak-sni".

    Also we shall pay attention to other possible leak sources (mostly on other aspects of TLS protocol).
]]

    I also tried unconditionally stripping SNI for all network requests: which has very few breakage.
    (most sites don't require it to properly function)

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Hi,

Not sending SNI is extremely likely to break the browsing experience, since it's not a fundamental part of how websites are served.
Most sites work, but any site that is colocated with others, or that is behind a load balancer will probably be affected. Even a 1% chance of breakage is too much when considering millions of users rely on it to just work.
If you really want to hide your browsing activity I suggest using Tor Browser or a VPN instead.

Additionally, I'd appreciate it if you didn't use weird syntax in your bugzilla comments.
I know you previously mentioned you're using an "AI assistant" for it. If it generated readable comments that would be fine, but the fact that it's a pain to read and make sense of it comes across as disrespectful - as in your time is worth much more than the developers' time you are directing your comments to.
In the future I urge you to use clear and simple language to express your thoughts. And especially on Bugzilla, adopting Github flavored markdown syntax will please a lot of the people reading your comments.

Thanks!

Comment 5

[Master ? [:masterquestionable]]

    Thanks for the reading.

    The title said: "Optionally".
    I of course understand the related implications and after careful consideration then proposed.
    And it definitely doesn't mean "send no SNI unconditionally".
    (and I believe, when properly implemented: it shouldn't break anything)

    "Tor Browser or a VPN"
<^>    No offense, but you seem to lack of understanding of the underpinnings.
    See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1848951#c12


    Regarding the off-topic:
    In brief: Less verbosity = More readability
    Feel free to further continue on [ https://github.com/MasterInQuestion/talk/discussions ].

    In the past I was over-focused on structure rigorousness to ensure general interoperability.
    Meanwhile underestimated the aspect of over-verbosity caused by unneeded content.
    And I thus have adapted specific changes for a reasonable compromise: between general rigorousness, and context-specific clarity.

    Most (mostly all) practical programming languages also exhibit similar problems to the schema I use:
    Syntax highlighting mostly required to maintain basic readability.
    (I also strived hard to mitigate this part in my design) [ Via exhaustive search of all possible symbols. ]

    Also, the problem in fact has little to do with Markdown really.
    (do a diff between the Refactored and Original you shall notice)

    Again, thanks for the reading.

    Note also, per Bugzilla's current design closing the issue preemptively tends to be counter-productive:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1887304#c0