Chromium Browser for Kicksecure Discussions (not Whonix)

Development
, ,
8

Now fixed.

1 Like
9

Awesome addition by @madaidan:

Dev/Chromium - Kicksecure

1 Like
10

Where should I include Micay’s writeups on browser sec?

EDIT:

Added here:

@madaidan. Please include any other useful posts by thegrugq and co.

2 Likes
11

Done: Dev/Chromium - Whonix

I used to have one from PaXTeam too but Redirect recently disabled comments. I’ll try to find an archived version.

1 Like
12

Found one: https://archive.fo/9aBLk

2 Likes
13

@nurmagoz

I have modified chromium comparison of chrome://flags to about:config:

For both examples mentioned, Chromium has the #legacy-tls-enforced option to disable legacy TLS ciphers (disabling legacy TLS ciphers is not useful anyway [1]) and has a more robust WebRTC IP handling policy to mitigate its privacy risks. WebRTC isn’t that big of an issue anyway. VPN clients can choose not to allow WebRTC traffic. It’s only leaky clients that have this issue.

[1]: Browser automatically choose the strongest TLS version that the website supports to connect to it. Disabling TLS ciphers, if anything worsens security. If a website only supports TLS 1.1 and you disable it, it will fall back to HTTP which is less secure. The only actual reason to do this is to push websites to switch to newer versions but this will only work if it’s done on a global level (i.e. Chrome and Firefox disable them by default). A few users disabling them won’t do anything. It could be useful to better prevent MITM attacks but only when you also enforce only HTTPS connections which is rarely done.

about:config has more settings than chrome://flags, sure but can you give any practical examples? The majority of them aren’t useful for the average user and are only used in incredibly niche situations.

1 Like
14

I guess the threat model @nurmagoz might have in mind here are TLS downgrade attacks. Suppose an adversary could break TLS 1.1 but not TLS 1.2.

(This is supposed to be a timeless argument. I.e. please don’t concentrate on 1.0 or 1.1 vs 1.2 etc.)

There used to be downgrade attacks where an MITM can force downgrade such as from y.y to x.x.

By disabling TLS 1.0 in theory before major browsers disabled TLS 1.0 by default one might have dodged such a downgrade attack?

Not necessarily.

  • Server side caused breakage: Website might even break since it does not allow non-https, http connections.
  • Browser side caused breakage: HSTS (preload) - if set up by that website - might also prevent non-https, http connections.

I guess the main motivation by @nurmagoz might not be to force websites to but to increase personal end user security? It might prevent a (at this time) unknown TLS1.3 to TLS1.2 downgrade attack. Thereby connection to that server might be more secure.

1 Like
15

legacy-tls-enforced option is about TLS version (TLS 1.0,1.1), im
talking about TLS ciphers SHA1,SHA256…

webRTC is leaky to the internal IP address even with Tor doesnt matter
what kind of protocol you gonna use. (if you search the internet for
what options should disabled in the web browser first one you gonna see
is webRTC. And i know there are workarounds for that like disabling JS
with noscript or use extension but that doesnt solve the main issue i
was talking about)

Despite that to not go into separate discussion of the usefulness or not
of disabling/enabling these options the concept is still valid that
chromium restrict or doesnt provide freedom of modification similar to
firefox.

madaidan via Whonix Forum:

16

Modern TLS versions prevent downgrade attacks in the protocol itself.

Downgrade protection: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack (see [BBFGKZ16], Definitions 8 and 9).

I guess an argument could be made about downgrading from TLS <1.3? I’m not sure if those versions have downgrade protection.

SHA isn’t cipher, it’s a hash function. Newer TLS versions don’t support old ciphers or hash functions. By dropping legacy TLS versions, you are dropping legacy ciphers.

Again, VPN clients can choose not to allow WebRTC traffic. It’s an issue present in a few VPN clients, not the browser itself. Besides, Chromium has robust safeguards against this.

Who cares that Firefox allows you to modify X random setting that nobody is ever going to use? Chromium isn’t worse just because it doesn’t bombard the user with thousands of settings that 99% of people are never going to use anyway.

17

SHA isn’t cipher, it’s a hash function. Newer TLS versions don’t
support old ciphers or hash functions. By dropping legacy TLS versions,
you are dropping legacy ciphers.

The option #legacy-tls-enforced in chromium doesnt disable TLS 1.0,1.1
they are still active despite activating it, it just enforces not to use
them. In FF they are totally disabled when choosing not to read that.

weak ciphers as: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ,
TLS_RSA_WITH_AES_128_GCM_SHA256 … cant be disabled within chromium and
there is no option to do that. Can be done through FF.

you can check your browser from here:

Chromium has robust safeguards against this.

im not sure regarding what you mean.

Who cares that Firefox allows you to modify X random setting that
nobody is ever going to use? Chromium isn’t worse just because it
doesn’t bombard the user with thousands of settings that 99% of people
are never going to use anyway.

Well it add a layer of control on the behavior of the browser even you
can disable JS readings from websites without the need to add new
extension (cant be done in chromium)…etc This is freedom,Control that
Chromium misses simple as that.

madaidan via Whonix Forum:

18

They are completely disabled with that option.

Neither of those are “weak ciphers”. AES-128 is still perfectly fine. Those examples aren’t the strongest cipher suites but that doesn’t mean they’re “weak”. They have never been broken.

Screenshot of Chromium with #legacy-tls-enforced enabled:

image

The WebRTC IP handling policy I mentioned earlier. It exposes multiple options on how to handle WebRTC connections, with the most strict being disabling non-proxied UDP.

JS can be disabled on Chromium via Settings → Site settings → JavaScript. It’s actually much easier, robust and more user-facing than anything in Firefox. It supports per-website rules and you don’t even need to go to chrome://flags.

It’s still not very useful for the average user. You have yet to give a single example that has a practical application.

19

Neither of those are “weak ciphers”. AES-128 is still perfectly fine.
Those examples aren’t the strongest cipher suites but that doesn’t
mean they’re “weak”. They have never been broken.

the weak problem is with the SHA, and weak doesnt mean broken because
thats going to be insecure.

Screenshot of Chromium with #legacy-tls-enforced enabled:

on my end tried it with chromium over debian doesnt block it, better
test on debian/kicksecure environments.

The WebRTC IP handling policy I mentioned earlier. It exposes
multiple options on how to handle WebRTC connections, with the most
strict being disabling non-proxied UDP.

oh but thats unrelated to the case im talking about disabling it
completely.

JS can be disabled on Chromium via Settings → Site settings →
JavaScript. It’s actually much easier, robust and more user-facing than
anything in Firefox. It supports per-website rules and you don’t even
need to go to chrome://flags.

ah so flags doest represent or has access to all options.

It’s still not very useful for the average user. You have yet to give
a single example that has a practical application.

Who talked about average user useful for him or not? doesnt matter, what
matter the controlability/freedom space of modification thats the only
point i raised.

20

There are more issues with those cipher suites than just SHA-1 (e.g. the first one uses CBC, the second one has no PFS, both use smaller AES key sizes). I still wouldn’t call it “weak” or say that it deserves to be disabled though. It’s not going to be realistically attacked currently.

I get the exact same result on both Arch Linux and Whonix/Kicksecure/Debian. You’re likely doing something wrong.

It’s not unrelated. This option does disable it.

No, and that was never the intention. Everything you’ll need will be in the ordinary settings or flags.

And that doesn’t really matter. Nearly the entire user base is going to be unaffected so it’s a weak point.

21

I get the exact same result on both Arch Linux and
Whonix/Kicksecure/Debian. You’re likely doing something wrong.

eeh just discovered that running chromium from terminal wouldn’t disable
that, only if running chromium from its icon. So yes it disable TLS
1.0,1.1 just not the others.(not sure where is the issue in here)

It’s not unrelated. This option does disable it.

Im lost, it disable webRTC completely or what?

Aside from that, chromium package outdated in debian mostly the
maintainer just quite or busy… do you have the capability to push the
new version in debian?

And do we have Apparmor/bubblewrap profiles for chromium?

madaidan via Whonix Forum:

22

On FF being more configurable…
Not that I think we identified any important setting the distribution or users must be able to change to make a good point for FF instead of chromium…

Ability to configure more could be possible through chrome (same for chromium?) policies?

On disabling of certain TLS versions or ciphers… If there is any security benefit if a distribution changed such default settings or if that was any useful if users did that… Please create a new forum thread for that. Since that discussion is kinda independent from this. Preferably with authoritative sources, experts explaining any threat model where this would lead to attack surface reduction, safer connections or anything else.

This is derived from the context of the discussion. Because of the title of this forum thread. Which default browser to choose.

Chromium Browser for Kicksecure Discussions (not Whonix)

Then also the link Dev/Chromium - Kicksecure is saying:

This page is a collection of notes, issues, criticism, advantages of Chromium. Development Considerations regarding default installation of Chromium in Kicksecure.

I should have added link to Dev/Default Browser - Kicksecure earlier or made that more clear.

Related, for most part unsolvable rabbit hole:
Selecting Secure Packages from packages.debian.org

With all due respect for all the work Debian people are doing, the maintenance of the Debian chromium package seems currently less than stellar.

Upstream Chrome (assuming same or similar for chromium, can’t easily find chromium stable release channel / versions) stable version is 86.0.4240. Debian Chromium version in Debian stable/testing/unstable is 83.0.4103.116 and Debian unstable has 84.0.4147. There is a good overview here:
Quote chromium - Debian Package Tracker

Not all issues in that list may be critical. Some issues could be considered minor. For example:

  • CVE-2020-15959: Insufficient policy enforcement in networking in Google Chrome prior to 85.0.4183.102 allowed an attacker who convinced the user to enable logging to obtain potentially sensitive information from process memory via social engineering.

But others sounds more severe:

  • CVE-2020-15960: Heap buffer overflow in storage in Google Chrome prior to 85.0.4183.121 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page.
  • CVE-2020-6537: Type confusion in V8 in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.

An even better overview of the Debian chromium package showing which CVEs are currently shown as vulnerable:
https://security-tracker.debian.org/tracker/source-package/chromium

Debian’s firefox-esr package has no such mentions:
https://tracker.debian.org/pkg/firefox-esr

But I guess @madaidan can pull out a reference showing how firefox-esr just means most security fixes are ignored and never back ported thereby relativize this?

So we have multiple different contests.

  • A) upstream Firefox vs upstream Chromium
  • B) Debian firefox-esr package vs Debian Chromium package
  • C) upstream Firefox vs upstream Chrome (irrelevant since Chrome isn’t fully Open Source)

Who’s the winner of each contest?

  • A) upstream Firefox vs upstream Chromium: Winner is Chromium.
  • B) Debian firefox-esr package vs Debian Chromium package?

Another option in theory for Kicksecure might be downloading packages for Debian from a another source (such as for example if Chromium provided these). But it doesn’t look as if these exist.

The chromium stable release channel links to, well, chrome. Not helpful.

There might be third parties providing alternative chromium packages. I’ve also seen download scripts before for chromium (similar to tb-updater) (non-package version). Or perhaps we would have to rely in a chromium (such as ungoogled-chromium if they did provide Debian stable (currently: buster) packages or any other chromium fork project?

Even having both apparmor and bubblewrap profiles for Firefox wouldn’t speak for Firefox in favor of Chromium since it comes with its own sandbox. It’s an important thing too but could be implemented on top as bonus at any later time.

1 Like
24

That doesn’t change anything. It’s disabled either way.

The others don’t need to be disabled.

It disables WebRTC unless it is proxied which mitigates the privacy risk.

sandbox-app-launcher works.

Policies do give fine-grained control over features in the browser but it’s not the same as about:config.

https://medium.com/@thegrugq/tor-and-its-discontents-ef5164845908

Tor Browser Bundle is based on a code base that may have publicly patched Critical or High bugs that are months old. And all the Medium and Low bugs are simply never patched (forever days, as they’re sometimes called.)

An adversary can do any number of things to attack the TBB, for example:

  1. Monitor for Critical / High patched vulnerabilities in the less stable channels (Nightly, Aurora, Beta) and then check whether the vulnerability exists and is exploitable in TBB. They have a window of exposure that might last weeks or months.
  2. Chain a series of Medium / Low vulnerabilities together until they get the level of access they require, e.g. remote code execution. They have a permanent window of exposure.

[…]

Tor Browser Bundle is at the tail end of the pipeline of patching (of which it receives only a minimal patch set)

With TBB’s base being Firefox ESR.

Maintenance of each ESR through point releases is limited to high-risk/high-impact security vulnerabilities

i.e. no Medium / Low vuln fixes

Still Chromium. The security gap between older versions of each browser is even larger than it is between recent versions. Firefox has been doing lots of catching up. E.g. Firefox’s sandbox is still quite recent when compared to Chromium.

Brave has a Debian repo: Installing Brave on Linux | Brave

Brave is a small bit behind on updates sometimes too although it’s nowhere near the lag of Debian and IME, it’s not too bad. It maybe has a few weeks lag at most.

You might not like Brave though due to its controversies in the past (BAT, auto-completing affiliate links, etc.)

https://twitter.com/BrendanEich/status/1269313200127795201

I don’t see any issues with the browser in its current state though. Any “iffy” features are opt-in and I’ve monitored the connections the browser makes myself to make sure it’s not privacy invasive.

They don’t provide packages themselves. There are only sketchy third-party ones: Downloads for ungoogled-chromium

Yes, an external sandbox like AppArmor or bubblewrap is not a replacement for a proper internal browser sandbox like in Chromium. Chromium’s sandbox is much more restrictive than anything we can add on top. It splits the browser up into multiple processes and sandboxes them individually with a really strict policy. Ideally, we would have both an internal and external sandbox.

1 Like
25

There’s no official stable chromium channel by upstream chromium.org? We couldn’t even have a script similar to tb-updater that downloads chromium stable, verifies gpg signatures (don’t exist)?

For all practical purposes, a chromium binary distribution doesn’t exist? (Major missing features such as stable release channel and gpg signatures.)

26

No. Only Chrome releases are provided.

1 Like
27

Quote Download latest stable Chromium binaries (64-bit and 32-bit)

Few free and open-source Chromium-based browsers:

Any of these forks or any others more suitable?

1 Like
28

It’s never a good idea to use forks because there will always be delays in applying patches compared to the base project - palemoon for example and other firefox forks are unsecure because of that.

2 Likes