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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
34 comments
[ 2.5 ms ] story [ 114 ms ] threadOS 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.
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.
What do you mean with "normal folks"? Nobody can possibly distinguish this, since an attacker would also just use a self-signed certificate.
https://www.sslshopper.com/ssl-checker.html#hostname=apple.c...
https://www.sslshopper.com/ssl-checker.html#hostname=www.app...
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.
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.
https://gist.github.com/dekz/7c911fa633e37fb130d4
Different root CA's?
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.
Ergo, encrypt everything, and the sensitive stuff can hide in a sea of meaningless traffic.
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....
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.
Edit: apple-store.com is obviously a real site, so let's say I find something just as legitimately looking as that.
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.
1: http://en.wikipedia.org/wiki/Extended_Validation_Certificate
Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...
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.