Comment by 1vuio0pswjnm7 | Hacker News Reader

Comment by 1vuio0pswjnm7 | Hacker News Reader

"Browsers receiving this traffic enforce that all certificates they receive come with a matching SCT, signed by a log provider they trust."

Interesting the word is "they" and not "you". Assuming "they" means the "tech" companies that provide these browsers and "you" means the computer owner.

Computer owners are usually given the run-time option to remove "trusted" root certificates that are pre-installed with browsers like Chrome. That is, remove them from the current list of trusted root certificates, not remove them from the source code. In a more perfect world, more computer owners could compile their own browsers,[FN1] thereby giving them the opportunity (freedom of choice) to remove untrusted certificates from the source code, as well as to add their own. Not to mention make other useful changes suitable to their own needs.

Can the computer owner remove a "trusted" log provider.

Can the computer owner add their own log provider.

FN1. I prefer to rely on a localhost proxy to perform TLS instead of the browser. One benefit is that I can read, edit and compile the proxy source code myself, quickly and easily. Unlike the graphical browser from the online ad services "tech" company, the author(s) of the proxy are not compromised by a pecuniary interest in selling and delivering programmatic advertising services, and the ability to use an in-house browser to support that pernicious endeavour. In using a proxy, I am not having to fight against the interests of the paternalistic browser vendor in order to protect my own.

> I prefer to rely on a proxy to perform TLS instead of the browser.

That's one step forward and about 30 steps backwards if you're actually doing that for security. Proxies silently accept broken TLS configuration all the time and serve then to you as https secured. You're unlikely to encounter invalid https configurations nowadays, so you likely won't ever notice, but it's definitely less secure to break the TLS connection in the proxy

> Proxies silently accept broken TLS configuration all the time

I don't want the browser to enforce TLS configuration; the proxy could be configurable to set it how I want it to accept or not accept broken TLS configurations.

Would be interested to see a list of those "about 30" steps. Surely, the number is neither made-up nor arbitrary.

I am not using a localhost proxy for "security". I do not use the proxy when performing any sort of commercial transaction or other important transaction using a graphical web browser issued by a "tech" company. That usage comprises a very small portion of overall computer use. I normally use TCP clients for making HTTP requests and a text-only browser for reading HTML.

> I prefer to rely on a localhost proxy to perform TLS instead of the browser.

I also would want to do this (it would be more efficient than needing to decrypt and encrypt it twice), but unfortunately the options for the proxy configuration does not seem to allow that.

I do not use the browser's proxy configuration. I use localhost DNS to direct HTTP traffic to the proxy. Alternatively one could use firewall rules.

That won't work for HTTPS unless you decrypt and encrypt it, which is less efficient, or not use HTTPS URLs, which will break many other things (and also has some inefficiencies when using with stuff that does use HTTPS), etc.

Efficiency is not the goal in my case. The localhost forward proxy does decrypt then re-encrypt according to how I have written the configuration, however that is exactly what I want because I need to be able to examine and manipulate HTTP requests and response bodies, among other things. Among the other things are, for example, specifying an acceptable TLS configuration, e.g., do not send SNI by default to all sites, use TLS1.3 only for sites that support it, and use ESNI for Cloudflare sites. These are options that a "modern" browser does not present to the user. If this setup was noticeabely slow I would not use it. IMO, it is faster than mitmproxy and requires less resources.

The proxy also converts http to https so all requests get encrypted regardless of which HTTP method is specified. "HTTPS everywhere" but not only for accessing www sites with a "modern" web browser but for any program with network access making DNS lookups and trying to make HTTP requests.

I generally do not use a "modern" browser. More often I use TCP clients that have no support for TLS. It is unlikely this setup would suit other computer users but it works for me.

If you don't mind, which proxy software(s) do you use for this?

In the past privoxy has been good but it seems quite neglected recently, especially wrt TLS-related functionality.

Haproxy

Reply on news.ycombinator.com