Q: How does gotofail.com work?
When you open gotofail.com some javascript runs that scans your user agent string to find out what browser and OS you're using. That information is used to classify you into one of several categories based on your detected OS/browser combination. The classes are:
- Your detected OS is not vulnerable: a message saying that will be shown without further tests, but you have the option force the test if you're paranoid.
- Your detected OS may be vulnerable but you are using a browser that's immune: you get a warning message recommending you re-test in Safari with a short explanation of other apps that are at risk from the bug.
- You are running OS X 10.9.2 on a browser that's immune: you will be told that you should be safe unless you're running a beta/prerelease version of OS X, and that if you don't know what that means you're fine.
- Your detected OS may be vulnerable and you are using a browser that hasn't been excluded as non-exploitable: an 'active' test is run to see if your browser continues to load a test message after seeing an invalid ServerKeyExchange packet (that would be bad) and either give you the scary red warning or a green safe message depending on the result.
Q: Can you explain like I'm five how the bug works?
Normal SSL/TLS:
- Client (browser): Hey server, let's speak in private. Here is a list of ciphers I know that we could use.
- RealServer: Okay, we can speak in private, here is my identification paperwork.
- Client: Your paperwork looks good, lets continue.
- RealServer: Let's use cipher XYZ. Please encrypt the conversation key you want to use to this public key. I have signed our conversation so far with the key from my identification paperwork to prove everything is legit.
- Client: Okay, your signature looks good, here's the conversation key encrypted so only you can read it. I am switching to cipher XYZ with that key now.
- Client and RealServer converse privately.
SSL/TLS with a vulnerable Apple product:
- Client (browser): Hey server, let's speak in private. Here is a list of ciphers I know that we could use.
- FakeServer: Okay, we can speak in private, here is my identification paperwork (RealServer's identification paperwork).
- Client: Your paperwork looks good, lets continue.
- FakeServer: Let's use cipher XYZ. Please encrypt the conversation key you want to use to this public key. Here's a picture of a cat I found, isn't it great?
- Client: Oh, sooo cute! What were we talking about? Oh yeah, here's the conversation key encrypted so that only you can read it. I am switching to cipher XYZ with that key now.
- FakeServer (thinking to itself): I can't believe Client fell for that trick. Now I just set up a conversation with RealServer...
- Client and RealServer converse with FakeServer able to see and change everything.
Q: What versions iOS are vulnerable?
iOS 6 from 6.0 to 6.1.5, iOS 7 from 7.0 to 7.0.5 and some beta/prerelease builds of 7.1.
Q: What versions of OS X are vulnerable?
10.9, 10.9.1 and some beta/prerelease builds of 10.9.2.
Q: Why do I get a yellow warning in Chrome/Firefox but green in Safari?
Firefox only provides the major release number, for example 10.9 or 10.8, in the user agent string. You'll also see this with Chrome on iPhone if you're jailbroken and have an unofficial patch. In either case, trust whatever message is shown in Safari.
Q: Why are my results wrong if I spoof my user agent string?
The result message mention scanning your operating system and browser version, if you are spoofing your user agent string that should cue you to temporarily disable spoofing.
Q: What does the backend look like?
Everything is static content to ensure that the load doesn't become a problem. The web server is vanilla nginx with a patched version of OpenSSL.
Q: Can I have the OpenSSL patch?
/*
Save as 'gotofail.c'
To build:
gcc -shared -fPIC -o libgotofail.so gotofail.c
To use:
LD_PRELOAD=./libgotofail.so PROGRAM AND ARGUMENTS GO HERE
*/
#define _GNU_SOURCE
int X509_check_private_key(void *a, void *b) { return 1; }