For easier reading and further commenting check here: https://security.stackexchange.com/...-exploitable-chrome-bundled-tls-mitm-backdoor Steps to reproduce the problem: Run Chrome with command line parameter: --cipher-suite-blacklist=0x9c,0x9d,0x2f,0x35,0xa or 0x000a,0x0009c,0x0009d,0x0002f,0x00035 or both together... then check out https://www.ssllabs.com/ssltest/viewMyClient.html Using the latest Chrome stable & Chrome beta the only cipher that can be disabled with --cipher-suite-blacklist= is 0xa, aka TLS_RSA_WITH_3DES_EDE_CBC_SHA, though as of late it must be renamed to 0x000a in order for the block to take place. What is the expected behavior? All weak ciphers should be disabled What went wrong? Chrome TLS is now less secure than ever. While 3DES_EDE is successfully disabled with "--cipher-suite-blacklist=" These cannot be disabled no matter what string you use: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128 TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 These ciphers are vulnerable to attacks via MITM... merely replace the cipher order in the hello packet with chromes weakest and boom, your a goner: 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/vulnera...odle-attack-bred-from-tls-flaw/d/d-id/1333815 Chrome developers have been abhorrent when it comes to cipher security. Users have been asking for 9 years for group policy and options to order and enable/disable ciphers and ECC. Nothing like this has been implemented, in fact they have now impaired our ability to turn off exploitable ciphers so chrome developers basically have implemented a defacto backdoor you cannot disable, leaving everybody is at risk. Anybody know how to disable this backdoor?
You have few extra zeroes in those ciphers. 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. But good god, can't Google give more friendly way to enable/disable ciphers than cmd-line I mean, even my crappy own privacy browser had better way, not only disabling/enabling but also specifying the order of ciphers wanted directly from GUI...and that was in 2013 ...
Well, Froberg, you and I are good right? Yea that still leaves 99.999998% of Chrome users vulnerable, at this time. They need to educate people more on ciphers, make it part of the in-browser settings just like cookies; billions of people are at risk right now. oh by the way don't forget to disable grease while your at it: chrome --cipher-suite-blacklist=0x009c,0x009d,0x002f,0x0035,0x000a,0x0A0A,0x1A1A,0x2A2A,0x3A3A,0x4A4A,0x5A5A,0x6A6A,0x7A7A,0x8A8A,0x9A9A,0xAAAA,0xBAA,0xCACA,0xDADA,0xEAEA,0xFAFA, and possibly 0x0A,0x1A,0x2A,0x3A,0x4A,0x5A,0x6A,0x7A,0x8A,0x9A,0xAA,0xBA,0xCA,0xDA,0xEA,0xFA as well, 317 characters just for ciphers, (before you figure out which ones need the extra zeros) to see just how pretty that fits with your 259 character windows shortcut limit, with all the the rest of your command line only security measures; i didn't realize until today i had to run chrome from a bat file just to make it secure.
Btw, you can disable TLS 1.0 with --ssl-version-min=tls1.1 switch There's also a #enforce-tls13-downgrade flag. Also, on another version without flags, I get Images: Passive | Yes on the mixed content tests, but when using a version with flags, I get No on the same test, and also the Yes is yellow (black is OK, Yes - dangerous but not too dangerous, Red - very bad) You can also use --ssl-version-min=tls1.2 , to be even more secure, but it's possible some sites not supporting TLS 1.2 to not work According to https://www.ssllabs.com/ssl-pulse/ , which checks the top 150k alexa sites? , 94.7% of sites support TLS 1.2
Even with TLS 1.2 you can connect by default using some relatively weak cipher suite. Switching to TLS 1.3-only browser would make too many websites unaccessible, unavailable.
Thank YOUUUU @floyd, yes anti tls 1.3 downgrade is currently available under about:flags. (nothing for tls 1.2 the 94% of websites use) min/max tls is available under "group policy" for Chrome in windows, mac and linux. However, all of this should be located under "options" and as accessible and informative as cookies... security is botched when trying to load a link from outside of the shortcut or commandline. Grease? I guess I confused that with QUIC, I will have to take a closer look here! LOL
I found some docs about Grease but I'm gonna read them some other time, they're going on my never-ending to-do list Spoiler https://tools.ietf.org/html/draft-ietf-tls-grease-02 https://www.thesslstore.com/blog/google-wants-grease-chrome/ https://www.chromestatus.com/feature/6475903378915328 -> https://bugs.chromium.org/p/chromium/issues/detail?id=648327 -> https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/d_f6higCJzc/R0QBCVKLAgAJ https://security.stackexchange.com/questions/176951/google-chrome-weird-random-cipher-suite https://lwn.net/Articles/701956/ https://news.ycombinator.com/item?id=17739342 https://community.qualys.com/thread/16765-new-suites-in-chrome
