openssl: apply yosemite certificate fix #38495
Conversation
|
Failure was unrelated. Looks good otherwise. |
|
Removed the |
|
👎; I think Misty's point that this is probably intentional is important. Even if it's a mistake I don't believe Homebrew should be making decisions about trust. |
FWIW, We already are. Just less explicitly. We choose to trust that Apple's keychains are secure over choosing to trust something like Mozilla's public bundle, and so on. Which is risky in itself, because we presume nothing has compromised the keychain or the user or piece of software hasn't inserted a rogue root. The trust is usually just much less explicit. As I said in the other thread, not attached to this PR. Asked whether a workaround was worthwhile, and this is the best workaround to there is to the situation. I don't love it either, but I don't love it because playing with roots is like sticking your hand in the devil's mouth and expecting that entity to not to set you on fire. We're trusting someone whatever decision we make in the end. |
|
I intended to express my opinion about whether we should accept this PR, not an opinion about your judgement. :) Your point that the system keychain was not received inscribed in stone from a pure, faultless deity is well taken. |
|
Apologies. Didn't mean to imply offence or anything, or rub you the wrong way either. I just find it hard to find nice things about the whole CA system, heh. Sent from my iPhone
|
|
Gmail does not work anymore because of this, if you use a client such as mutt[1], or have a script that uses, e.g., the ruby imap library. Something has to be done, in Homebrew, even if it is merely putting temporary advice in a prominent place about how to workaround the bug. As long as @DomT4's tweak is removed as soon as the situation is fixed, I don't see what's wrong with it. It merely puts 10.10 users in the same "trusty" position as Mavericks users (unless...Oh God, did the Security Update for Mavericks break it there too?). [1] Actually, one can get around this in mutt by manually accepting the cert when mutt prompts you, but this is basically the same as @DomT4's solution: it puts the cert on your machine, where it will be accepted by mutt until you delete it. |
|
Given that even the recent RapidSSL SHA256 intermediate CA goes back to the Equifax root (as signer of the GeoTrust Global CA), this is going to be a lot of fun to get rid off. There's a vast number of RapidSSL DV certs out there… Not putting a fix for this in homebrew just puts the burden of brewing their own ca bundle on the users, which will most likely carry out the first fix they find on google instead of a minimally invasive change as proposed by this PR. |
|
Doing |
|
Pushed. Happy to revisit this and remove it when at least |
|
Should clarify that a GeoTrust Global CA certificate with fingerprint DE 28 F4 A4 FF E5 B9 2F A3 C5 03 D1 A3 49 A7 F9 96 2A 82 12 which is listed on the Geotrust roots page is and has been an OS X trusted root. When I connect to google.com with openssl s_client I see trust is mediated through a certificate with subject CN=GeoTrust Global CA with fingerprint 73:59:75:5C:6D:F9:A0:AB:C3:06:0B:CE:36:95:64:C8:EC:45:42:A3 which is signed by the outgoing Equifax Secure Certificate Authority root. This certificate presents the same public key as the certificate with the same CN but a different fingerprint in the OS X trust store. I don't understand why a trust path can't be constructed which terminates at the trusted GeoTrust Global CA certificate since the public keys match. |
|
This apparently outstanding OpenSSL issue may be relevant: https://rt.openssl.org/Ticket/Display.html?id=2732&user=guest&pass=guest |
|
The validation path is presented by the server: https://tools.ietf.org/html/rfc5246#section-7.4.2 |
|
Just to confirm, this impacts LibreSSL as well. On the upside, very little is built against LibreSSL right now. |
|
Adam Langley at Google was kind enough to reply on the Google cert issue:
|
|
That sounds like a wontfix. Openssl is doing this, though, isn't it, not OS
X?
|
|
Yeah, It's a shared OpenSSL/LibreSSL failure. Secure Transport is actually working in this case. Using Interestingly, both OpenSSL and LibreSSL will actually make secure connections against Google.com via If you do instead Welp. |
|
There's an old 2009 Ubuntu bug on the |
|
So, is this bug in openssl actually reported to them? As in, within the last couple of days? I tried looking on rt.openssl.org, but I find that site opaque. I hate to think what we're in for, if the reports linked to in this thread have just languished unfixed for years. |
|
Also: this bug doesn't seem to affect the system openssl on 10.10.3. Is that because it just doesn't affect old versions of openssl, or is it because Apple have patched their way around this? |
|
If you want to check the openssl098 formula in -versions that could shed light. |
|
You're right about the system OpenSSL. Just did a full |
|
Our System is |
|
Diff of headers between Apple OpenSSL 0.9.8zd and Homebrew OpenSSL 0.9.8zd. If you throw it an editor that colorises diffs automatically, it's a lot easier to read. Aside Apple's love of deprecating stuff, there's a few completely new files and some semi-interesting |
|
I've just discovered more instances of what must be dropped certs. When I try to use mutt on a hotmail account, I am now (10.10.3) getting asked to manually accept the following two certs, which used to be handled automatically by the system certs wedged into openssl: And, If I temporarily replace BTW, I apologize if this is noise and not adding anything of interest. (I don't know much about certs, other than "they exist, and they have to do with security".) Perhaps this is some evidence that we're dealing with an Apple bug after all. |
|
@chdiza If you have a copy of the untouched 10.10.2 keychain-generated |
|
Thanks! Did you add the Equifax cert back? The top cert in green is the Equifax cert that's supposed to be missing on 10.10.3. Unless in this case, green = removed and red = added. My brain is barely functioning today, I've apparently forgotten how to read a diff 😖 |
Yeah, I forgot, I did add it back. I added it to the System keychain, which means brewing openssl put it into osx_cert.pem. |
|
Are these things base64 encoded in the .pem files? |
Cool, thanks. That was confusing me 😸.
Yup. Looks like it. |
|
Everything added and removed in 10.10.3: Clicky. Base64 is a nightmare to work with. |
|
The latest news here is... not great. Essentially, we're going to be waiting on OpenSSL to fix their cert chain building, so... yeah. Next step is filing a bug report with OpenSSL and OpenBSD. |
|
Reported upstreams: |
|
@DomT4 Thanks for filing those! The four-year waiting period for a fix has thus begun :) |
This *will* land in 1.0.2b, but it's a better solution than us applying an old, outdated, weak Equifax cert till that point. I've pinged OpenSSL to check I'm not being stupid to cherry-pick these patches, but they should be fine - I pulled both related patches, so it's not like we're being overly selective. I also asked whether there was a release schedule for the 1.0.2b release with these fixes, but I don't particularly expect to be given an answer given OpenSSL's often (understandably) sensitive release schedule. Fixes #38495 Fixes #38491 Upstream discussion: https://www.mail-archive.com/openssl-dev@openssl.org/msg38674.html Closes #38897. Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
This *will* land in 1.0.2b, but it's a better solution than us applying an old, outdated, weak Equifax cert till that point. I've pinged OpenSSL to check I'm not being stupid to cherry-pick these patches, but they should be fine - I pulled both related patches, so it's not like we're being overly selective. I also asked whether there was a release schedule for the 1.0.2b release with these fixes, but I don't particularly expect to be given an answer given OpenSSL's often (understandably) sensitive release schedule. Fixes Homebrew#38495 Fixes Homebrew#38491 Upstream discussion: https://www.mail-archive.com/openssl-dev@openssl.org/msg38674.html Closes Homebrew#38897. Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Emergency workaround for #38491.