Help
Post your comments for Keep your Mac safe from Web security flaws here
Keep your Mac safe from Web security flaws
#3
lookatthisguy 
- Member
-
- Group: Members
- Posts: 24
- Joined: 20-October 09
Posted 23 September 2011 - 03:38 PM
lewk, on 23 September 2011 - 03:04 PM, said:
The options you recommend are grayed out in Keychain Access 4.1.1 under Snow Leopard. My only choices are Best Attempt or Off. :-\ Any suggestions
Same issue for me. Hold down Option when you click on the pop-up menu, and that should allow it. It did for me at least.
#4
schoonerman
- Member
-
- Group: Macworld Insiders
- Posts: 454
- Joined: 16-October 04
Posted 23 September 2011 - 03:56 PM
For Firefox, there is also a "Certificate Patrol" add-on. This can get noisy in the beginning: it's job is to tell you when a site uses a different certificate than it did last time you went there (or when you go there for the first time). Early use of Certificate Patrol uncovered the fact the gmail.com uses different certificates depending on which server you happen to connect to in the load balancing operation. Certificate Patrol has worked around that problem.
Once you've been everywhere you're likely to go with HTTPS in Firefox, Certificate Patrol will let you know about things like renewed certificates and real attempts to lie to you. (Be suspicious if a certificate is renewed months before it is due to expire, although an early example of that oddity turned out to be legitimate.)
--John Baxter
Once you've been everywhere you're likely to go with HTTPS in Firefox, Certificate Patrol will let you know about things like renewed certificates and real attempts to lie to you. (Be suspicious if a certificate is renewed months before it is due to expire, although an early example of that oddity turned out to be legitimate.)
--John Baxter
John W Baxter
#5
macplusplus
- Member
-
- Group: Members
- Posts: 34
- Joined: 08-September 11
Posted 23 September 2011 - 07:37 PM
"Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That's illogical, and presumably Apple will fix this bug in the future. "
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a certificate chain than those used for its non-EV certificates.
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a certificate chain than those used for its non-EV certificates.
#6
macplusplus
- Member
-
- Group: Members
- Posts: 34
- Joined: 08-September 11
Posted 23 September 2011 - 07:38 PM
macplusplus, on 23 September 2011 - 07:37 PM, said:
"Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That's illogical, and presumably Apple will fix this bug in the future. "
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a certificate chain than those used for its non-EV certificates.
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a certificate chain than those used for its non-EV certificates.
read it as "... under a different certificate chain than..."
#7
Glenn_Fleishman
- Member
-
- Group: Macworld Insiders
- Posts: 605
- Joined: 13-October 01
Posted 23 September 2011 - 08:29 PM
macplusplus, on 23 September 2011 - 07:37 PM, said:
"Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That's illogical, and presumably Apple will fix this bug in the future. "
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a different certificate chain than those used for its non-EV certificates.
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a different certificate chain than those used for its non-EV certificates.
Definitely a problem, but expect that if CAs continue to fall to compromises, sites such as (perhaps) Macworld would provide advice as to which CAs to untrust. You shouldn't have to figure that out.
#8
macplusplus
- Member
-
- Group: Members
- Posts: 34
- Joined: 08-September 11
Posted 23 September 2011 - 08:48 PM
Glenn_Fleishman, on 23 September 2011 - 08:29 PM, said:
macplusplus, on 23 September 2011 - 07:37 PM, said:
"Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That's illogical, and presumably Apple will fix this bug in the future. "
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a different certificate chain than those used for its non-EV certificates.
What if you distrust the wrong root certificate? A CA may issue its EV certificates under a different certificate chain than those used for its non-EV certificates.
Definitely a problem, but expect that if CAs continue to fall to compromises, sites such as (perhaps) Macworld would provide advice as to which CAs to untrust. You shouldn't have to figure that out.
On OS X the user cannot manipulate EV Roots by means of the Keychain Access utility. Those are kept in /System/Library/Keychains/EVRoots.plist file. So apparently the verification of an EV certificate follows a different path than a non-EV certificate on OS X. This is not Safari's bug, simply an implementation choice. Count the number of EV root certificates shown in Keychain Access: there is none...
#9
Glenn_Fleishman
- Member
-
- Group: Macworld Insiders
- Posts: 605
- Joined: 13-October 01
Posted 23 September 2011 - 08:52 PM
macplusplus, on 23 September 2011 - 08:48 PM, said:
On OS X the user cannot manipulate EV Roots by means of the Keychain Access utility. Those are kept in /System/Library/Keychains/EVRoots.plist file. So apparently the verification of an EV certificate follows a different path than a non-EV certificate on OS X. This is not Safari's bug, simply an implementation choice. Count the number of EV root certificates shown in Keychain Access: there is none...
I'm expecting Apple will fix this obvious problem that prevents overriding trust revocation.
#10
PixelHermit
- Member
-
- Group: Members
- Posts: 15
- Joined: 28-January 09
Posted 24 September 2011 - 05:35 AM
After following the advices in the article, when I start iTunes a message pops up saying that the "certificate for the server 'p7-buy.itunes.apple.com' isn't valid". Apparently even Apple find it somewhat of a struggle to keep their certificates up to date...
#11
macplusplus
- Member
-
- Group: Members
- Posts: 34
- Joined: 08-September 11
Posted 24 September 2011 - 06:25 AM
PixelHermit, on 24 September 2011 - 05:35 AM, said:
After following the advices in the article, when I start iTunes a message pops up saying that the "certificate for the server 'p7-buy.itunes.apple.com' isn't valid". Apparently even Apple find it somewhat of a struggle to keep their certificates up to date...
Funny indeed
This is because of the option "Require if the certificate indicates". If the OCSP/CRL servers (those tell us whether the certificate has been revoked or not) cannot be contacted, this option assumes the verification failed. Probably the next time the servers will be contacted and the verification going smoothly the message will not appear again. Apple's default is "Best Attempt", which assumes the verification OK in case of communication failure. This is rather a matter of user experience at this point. Displaying an avalanche of alerts in Windows style loosens the effectiveness of the alerts within time. If you are addicted to alerts leave it at "Require if certificate indicates".
#12
Glenn_Fleishman
- Member
-
- Group: Macworld Insiders
- Posts: 605
- Joined: 13-October 01
Posted 24 September 2011 - 06:39 AM
macplusplus, on 24 September 2011 - 06:25 AM, said:
Displaying an avalanche of alerts in Windows style loosens the effectiveness of the alerts within time. If you are addicted to alerts leave it at "Require if certificate indicates".
The point of this article is how to configure your Mac so that you aren't taken hostage by suborned certificates. The point of changing that setting isn't to be bombarded by security warnings; rather, to set a higher level of alertness.
#13
cv
- Member
-
- Group: Members
- Posts: 384
- Joined: 08-December 06
Posted 24 September 2011 - 08:17 AM
One of the most effective ways at reducing security risks is to stop using webmail (Gmail, Yahoo, Hotmail, AOL mail, etc.) and access your e-mail with a standalone e-mail client. Even better, use that e-mail client on a device that doesn't have Adobe Flash or Adobe Acrobat Reader.
#14
Glenn_Fleishman
- Member
-
- Group: Macworld Insiders
- Posts: 605
- Joined: 13-October 01
Posted 24 September 2011 - 08:44 AM
cv, on 24 September 2011 - 08:17 AM, said:
One of the most effective ways at reducing security risks is to stop using webmail (Gmail, Yahoo, Hotmail, AOL mail, etc.) and access your e-mail with a standalone e-mail client. Even better, use that e-mail client on a device that doesn't have Adobe Flash or Adobe Acrobat Reader.
Standalone email clients that use SSL/TLS sessions aren't susceptible to this particular crack, but are still at risk to other certificate flaws. For instance, the Comodo or DigiNotar suborned certificates would have allowed interception of secured email sessions just as they would have secured Web sessions.
