Apple.com currently has a self-signed certificate (fixed now)(apple.com)
apple.com
Apple.com currently has a self-signed certificate (fixed now)
https://apple.com/
apple.com currently does not have a valid certificate. Note that I'm accessing the page from Europe, so this is not the issue with China MITM-ing iCloud.
8 comments
Turns out this breaks Xcode documentation and simulator updates, too. Nice job, Apple.
Strange. I get that too. Certificate is signed by "Apple IST CA 2 - G1", with 256-bit RSA. Of course accessing their website normally doesn't go through SSL so most people won't see this.
Go to https://www.apple.com and not https://apple.com to get the correct site with the proper certificate. apple.com != www.apple.com
Indeed, they have different hosts. akamai appears to host all of www.apple.com while the non-www server is hosted directly at 17.142.160.59 (primary), 17.178.96.59 (forwards for a lot of Apple domain names) or 17.172.224.47 (also forwards for a lot of domain names...). Oddly enough, only 17.178.96.59 has a proper certificate, but it's signed with Apple IST CA 2 - G1 from GeoTrust rather than VeriSign used everywhere else. They appear to have a misconfiguration for the other two servers configured in DNS to serve apple.com. Apple IST probably stands for Information Services and Technology group at Apple.
I know, but I always just type apple.com. It is still a problem.
Not anymore. They added a redirect.
OS X talks to plenty of apple.com subdomains and there really is no reason not to use self-signed certificates for this kind of thing.
OS X talks to plenty of apple.com subdomains and there really is no reason not to use self-signed certificates for this kind of thing.
the redirect happens _after_ the certificate warning. to get to the redirect, you have to accept the self signed certificate first.
so it might still scare people away, and rightfully so: normal folks cannot distinguish a self signed certificate from a malicious used one f.e. used in phishing attempts.
so it might still scare people away, and rightfully so: normal folks cannot distinguish a self signed certificate from a malicious used one f.e. used in phishing attempts.
> normal folks cannot distinguish a self signed certificate from a malicious used one
What do you mean with "normal folks"? Nobody can possibly distinguish this, since an attacker would also just use a self-signed certificate.
What do you mean with "normal folks"? Nobody can possibly distinguish this, since an attacker would also just use a self-signed certificate.
You're right, of course. Did they change the certificate?
https://www.sslshopper.com/ssl-checker.html#hostname=apple.c...
https://www.sslshopper.com/ssl-checker.html#hostname=www.app...
https://www.sslshopper.com/ssl-checker.html#hostname=apple.c...
https://www.sslshopper.com/ssl-checker.html#hostname=www.app...
Hmm, I don't seem to get that. While it seems unlikely, could you be getting MitM'ed?
Ah wait, are you only getting it on "https://apple.com"? In my Chrome browser, that immediately redirects to www.apple.com -- but if the first one was self-signed, wouldn't it be untrusted by the browser, and wouldn't the browser refuse to redirect and give me a warning instead?
Confused as to if I'm seeing the same thing as you or not.
Ah wait, are you only getting it on "https://apple.com"? In my Chrome browser, that immediately redirects to www.apple.com -- but if the first one was self-signed, wouldn't it be untrusted by the browser, and wouldn't the browser refuse to redirect and give me a warning instead?
Confused as to if I'm seeing the same thing as you or not.
https://apple.com does redirect to https://www.apple.com, but it does so with an Apple-issued certificate. Are you running Chrome on OS X?
If you use curl/wget/similar on a machine that doesn’t have Apple’s certificates installed the 301 fails (bad cert).
"curl: (60) Peer certificate cannot be authenticated with known CA certificates”
Oddly, when I first tried to load https://apple.com inside Vienna (OS X RSS reader) it refused to load (bad cert), now it loads fine. Hmmm.
If you use curl/wget/similar on a machine that doesn’t have Apple’s certificates installed the 301 fails (bad cert).
"curl: (60) Peer certificate cannot be authenticated with known CA certificates”
Oddly, when I first tried to load https://apple.com inside Vienna (OS X RSS reader) it refused to load (bad cert), now it loads fine. Hmmm.
I am using Chrome on OSX and do not get it:
https://gist.github.com/dekz/7c911fa633e37fb130d4
https://gist.github.com/dekz/7c911fa633e37fb130d4
I too am using Chrome on OSX.
Different root CA's?
Different root CA's?
Strange, but someone else saw it, too. Maybe they have fixed it on some of their servers.
[deleted]
+1 I only get it without the www; chrome doesn't let me redirect away either
This is so frustrating. So many sites are still accessible over HTTP. Perhaps some of the security tools out there (a la ssllabs.com) should start giving you a warning, etc. for serving anything but a 301 over HTTP.
Also, really, Apple can't figure out how to get a wildcard cert and properly install it? I had an idea at one point to put together an bot to scan and publicly shame Alexa top whatever sites if they don't do HTTPS properly and consistently. Perhaps I should go back to that idea.
Also, really, Apple can't figure out how to get a wildcard cert and properly install it? I had an idea at one point to put together an bot to scan and publicly shame Alexa top whatever sites if they don't do HTTPS properly and consistently. Perhaps I should go back to that idea.
Extended validation certificates[1] (the fancy ones with the green URL bar) aren't allowed to contain wildcard entries.
1: http://en.wikipedia.org/wiki/Extended_Validation_Certificate
1: http://en.wikipedia.org/wiki/Extended_Validation_Certificate
Then don't use EV? EV certs are generally pretty dubious, but I imagine the distinction between self-signed or no cert vs non-EV valid cert is pretty big.
Browser makers are starting to really de-emphasize domain validated certs in favor of EV. In many cases now, non EV certs don't trigger anything to be green in the browser address bar:
Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...
Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...
Why do all sites need to be HTTPS?
What justizin said. Also, let's say that I am able to MitM your connection to apple.com. You are a brand new customer, credit card in hand, ready to buy yourself a brand new $5,000 Mac Pro, and a couple of Cinema displays. You open up Chrome, go to apple.com, but instead of getting the real deal, you get my slightly modified version. The change? I run a regex on all the HTML served (that's right, I'm a real h@x0r, and regex my HTML like a boss) that does s/store\.apple\.com/apple-store.com/g. Now, apple-store.com has its own valid SSL cert, so you get the nice green bar when you get to https://apple-store.com. This site is mine, and all it does is serve the content from the legitimate store.apple.com, except it also injects a small script into the payment form. As soon as you type in your credit card info, it is mine. Moreover, I know exactly how much you spent, and maybe I even allow you to place the order, get all the confirmations, etc. You won't know that something went wrong until I sell your CC number on the black market and some guy in Uzbekistan buys himself an iPhone 6 Plus with your money.
Edit: apple-store.com is obviously a real site, so let's say I find something just as legitimately looking as that.
Edit: apple-store.com is obviously a real site, so let's say I find something just as legitimately looking as that.
If you only encrypt your most important secrets, they are far more vulnerable to attack. Sometimes what you hide can be inferred by what you don't, etc..
I hear you, though, it's a real pain, but welcome to 2014, we're all learning more about crypto than we ever thought we would have to know, which is what crypto experts have been telling us for 20+ years we would have to do.
I hear you, though, it's a real pain, but welcome to 2014, we're all learning more about crypto than we ever thought we would have to know, which is what crypto experts have been telling us for 20+ years we would have to do.
The typical argument is if only sensitive traffic is encrypted, you know that something is worth attacking because it is encrypted.
Ergo, encrypt everything, and the sensitive stuff can hide in a sea of meaningless traffic.
Ergo, encrypt everything, and the sensitive stuff can hide in a sea of meaningless traffic.
There not much I really need to have encrypted, my bank website, my emails, my files on cloud services and my ssh sessions.
Anyone that can do a MITM over HTTPS can really easily find the hostname of all theses IP. in fact anyone could find the hostname of theses IP....
Anyone that can do a MITM over HTTPS can really easily find the hostname of all theses IP. in fact anyone could find the hostname of theses IP....
And every password and login form you use to protect your passwords. And every government form you fill out (they often require personal identifying info). And every link that links to those forms, etc. There are a lot more ways to attack a connection than just hijacking a cleartext bank password.
That's why I double and triple check the URL on important service before I fill out everything.
Unencrypted channels can be spied on to see which pages you're looking at, or hijacked to serve malware. Note that even with HTTPS, a passive sniffer can tell which domains you're visiting.
Even a blog should be served over HTTPs. There's opportunity to inject JS for a MITM attack. Greyhound wifi does this all the time.
Something more interesting: if your site provides something like a code snippet, a MITM could change it.
A lot of download sites serve downloads on http. A MITM could change out the binary. This is especially bad if you're downloading something like a library (example: zeptojs, foundation by zurb)
So yeah. There's a lot of attack vectors. Do your best to minimize it even if you can't think of anything.
Something more interesting: if your site provides something like a code snippet, a MITM could change it.
A lot of download sites serve downloads on http. A MITM could change out the binary. This is especially bad if you're downloading something like a library (example: zeptojs, foundation by zurb)
So yeah. There's a lot of attack vectors. Do your best to minimize it even if you can't think of anything.
They don't. And shouldn't be,
Apparently you've a 50/50 chance of hitting a self-signed certificate? https://www.ssllabs.com/ssltest/analyze.html?d=apple.com&hid... (Click on each IP address to view the results)
Correction: Qualys' tool merges tests of apple.com and www.apple.com. In fact, you've a 66% chance of getting a self-signed certificate, as the IP addresses starting with 17 are the ones serving the non-www apple.com redirect. This is clearly indicated by the "Domain" column of the table, which I apparently completely missed until just now.
Correction: Qualys' tool merges tests of apple.com and www.apple.com. In fact, you've a 66% chance of getting a self-signed certificate, as the IP addresses starting with 17 are the ones serving the non-www apple.com redirect. This is clearly indicated by the "Domain" column of the table, which I apparently completely missed until just now.
Their actual shopping website is less ambiguous: https://www.ssllabs.com/ssltest/analyze.html?d=store.apple.c...
Well, that's unexpected. You have to visit https://apple.com to hit the self-signed URL.
'oh no'