Apple.com currently has a self-signed certificate (fixed now)

by quonn • 12 years ago

44 33 12 years ago

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.

M4v3R• 12 years ago

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.

capecodcarl• 12 years ago

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

quonn3• 12 years ago

I know, but I always just type apple.com. It is still a problem.

teamhappy2• 12 years ago

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.

lstamour3• 12 years ago

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.

jrochkind12• 12 years ago

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.

quonn3• 12 years ago

Strange, but someone else saw it, too. Maybe they have fixed it on some of their servers.

jackweirdy• 12 years ago

+1 I only get it without the www; chrome doesn't let me redirect away either

roghummal• 12 years ago

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.

dekz• 12 years ago

I am using Chrome on OSX and do not get it:

https://gist.github.com/dekz/7c911fa633e37fb130d4

jrochkind12• 12 years ago

I too am using Chrome on OSX.

Different root CA's?

IgorPartola4• 12 years ago

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.

Kiro• 12 years ago

Why do all sites need to be HTTPS?

sliverstorm• 12 years ago

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.

justizin• 12 years ago

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.

sp332• 12 years ago

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.

jbb555• 12 years ago

They don't. And shouldn't be,

IgorPartola4• 12 years ago

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.

pwnna• 12 years ago

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.

hansnielsen• 12 years ago

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

IgorPartola4• 12 years ago

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.

lstamour3• 12 years ago

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.

lstamour3• 12 years ago

Their actual shopping website is less ambiguous: https://www.ssllabs.com/ssltest/analyze.html?d=store.apple.c...

Mandatum• 12 years ago

Well, that's unexpected. You have to visit https://apple.com to hit the self-signed URL.

digitalpacman• 12 years ago

'oh no'

ahknight• 12 years ago

Turns out this breaks Xcode documentation and simulator updates, too. Nice job, Apple.

Apple.com currently has a self-signed certificate (fixed now)

Related Stories