-5

Multiple vulnerabilities have basically obsoleted TLS_RSA, CBC and QUIC implementations.

February 9, 2019:

"Seven researchers from all over the world found --yet again-- another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google's new QUIC encryption protocol as well."

https://www.zdnet.com/article/new-tls-encryption-busting-attack-also-impacts-the-newer-tls-1-3/

Feburary 8 2019:

"Craig Young, a computer security researcher for Tripwire's Vulnerability and Exposure Research Team, found vulnerabilities in SSL 3.0's successor, TLS 1.2, that allow for attacks akin to POODLE due to TLS 1.2's continued support for a long-outdated cryptographic method: cipher block-chaining (CBC). The flaws allow man-in-the-middle (MitM) attacks on a user's encrypted Web and VPN sessions."

Source: https://www.darkreading.com/vulnerabilities---threats/new-zombie-poodle-attack-bred-from-tls-flaw/d/d-id/1333815

Answer #1 below explains how to disable some these by command line, however unpractical it is to do so. Part of the answer involves browser developers making cipher selection far more accessible to your average user; for example, make them as accessible as cookie settings.

2
  • Let us continue this discussion in chat.
    – schroeder
    Feb 12, 2019 at 11:13
  • Your link for the Bleichenbacher attack states that Chrome is not vulnerable (Chrome uses BoringSSL). So disabling TLS_RSA is unnecessary in Chrome.
    – schroeder
    Feb 12, 2019 at 19:34

1 Answer 1

-4

This effectively worked for me on the latest Chrome Beta. Google has since disabled QUIC on youtube, but just to be safe, don't forget to disable QUIC under about:flags.

Quoting what another source told me:

At least latest windows version of Chrome works with this:

chrome --cipher-suite-blacklist=0x009c,0x009d,0x002f,0x0035,0x000a

That makes all the TLS_RSA_* ciphers go away.

Can't Google give more friendly way to enable/disable ciphers than the command line? I mean, even my crappy own privacy browser had a better way, not only disabling/enabling but also specifying the order of ciphers wanted directly from GUI...and that was in 2013 ... "

I too find chromes weak command line only implementation impractical, while also omitting security entirely when loading URL's outside of the 'shortcut' or commandline, like an email application or "Microsoft" help URL. Also, one must check routinely to ensure google has not changed the commandline code yet again (which broke my previous settings), or as I have, switch to FireFox.

The most reasonable answer is to fix the problem at the source. I have made a feature request, you can add your rationale for adding better functionality on my bug report/feature request. This will also allow users to remove vulnerable ciphers in zero-day instances, rather than having to wait for developers to plug the holes.

Browser developers need to educate people far more on ciphers, make it just as accessible and informative as cookies; this is critical. Billions of people are at risk without practical measures.

1
  • 3
    As noted by a Chromium dev here, disabling these ciphers on your client doesn't protect you. If the server supports the ciphers using a vulnerable library (the ciphers themselves are not vulnerable, it is certain implementations) then an attacker can use the vulnerability to exploit otherwise secure ciphers as well. Feb 12, 2019 at 17:13

Not the answer you're looking for? Browse other questions tagged .