Consider this scenario: Someone logs on to amazon.com using password xyz123. Then, they logon to gmail, where their password is also xyz123. Then, they logon to Facebook, where, yet again, their password is xyz123.
In this day and age, who would do such an obviously insecure thing as re-using the same password over and over again?
Yes, that Apple, the richest company in the world. The company famous for fighting the FBI over an iPhone password. Let me explain.
My last blog noted that the US Social Security Administration did a great job configuring the security for www.ssa.gov, yet the security for the secure.ssa.gov section of their site was poor. Considering the "secure" section is where you login, this could be taken as proof the government learned nothing from the Office of Personnel Management hack.
A recent iToy purchase prompted the same sort of security evaluation for Apple's website. As before, I used the excellent SSL Server Test from SSL Labs/Qualys.
The main Apple website, like most every site, can be addressed as either apple.com or www.apple.com.
With three Ws, the site gets a B rating from SSL Labs. It's one failing: "This server accepts RC4 cipher, but only with older protocol versions." Without the leading Ws, the site gets an A minus. This time, the lone failing is different: "The server does not support Forward Secrecy with the reference browsers."
Its not clear to me that any confidential information is entered on the website using either apple.com or www.apple.com so these are probably minor issues.
Let me back up here to note that it is perfectly normal for different sections of a website to have different security profiles. The sections are denoted by subdomains which appear to left of the main domain name.
For example, the main apple domain is apple.com and "www" is a subdomain. Two other Apple subdomains are support.apple.com and iforgot.apple.com. In the case of the Social Security Administration, the main domain name is ssa.gov and two of their subdomains are secure.ssa.gov and faq.ssa.gov.
While buying an iDevice, account information is entered at secure2.store.apple.com which gets an A plus rating from SSL Labs - not a single security issue.
Support.apple.com gets an A minus, due to two security flaws: "Intermediate certificate has a weak signature" and "There is no support for secure renegotiation." But here too, this subdomain does not seem to be used for transferring sensitive information.
The same can not be said of getsupport.apple.com. This part of the website is where Apple customers enter their personal information so that they can connect with technical support. The personal information can be the customer name, email address and phone number. According to SSL Labs, this section of the site has a single security failing: "There is no support for secure renegotiation."
A COMMON FLAW
The real trouble, as I see it, is in the sections of the website that deal with an Apple ID and password.
For example, customers wanting to reset either their password or their security questions are directed to iforgot.apple.com. This section gets an A minus (see report above) with two errors: "Intermediate certificate has a weak signature" and "The server does not support Forward Secrecy with the reference browsers."
Another section of the website where users logon with their Apple ID and password is idmsa.apple.com. It too, does not support Forward Secrecy.
Neither does www.icloud.com, the report is shown above.
I am no expert regarding Apple's website, but it seems that every section where a customer enters their Apple ID and password fails to implement Forward Secrecy. This despite, as the other examples showed, Apple using Forward Secrecy elsewhere.
WHY YOU SHOULD CARE
Forward secrecy (a.k.a. Perfect Forward Secrecy, PFS and just plain FS) is a rather obscure SSL/TLS option and SSL/TLS is the protocol that makes secure web pages secure.
Back in 2013, when I first wrote about it, you had to be quite a nerd to determine if a connection to a secure website was using Perfect Forward Secrecy (if the key exchange is ECDHE_RSA or DHE_RSA then it is). Even now, some online SSL testers (here, here and here) don't report on Forward Secrecy. SSL Labs offers the most in-depth report, showing the status of Forward Secrecy with a large range of client software. Both High-Tech Bridge and Netcraft report on it, but with a simple ON/OFF.
While the details of Forward Secrecy are complicated (and over my head) the basic concept is simple. Without it, a website uses the same encryption password (the official term is a "key" but it functions much like a password) over and over and over. Day after day, for a year or two. Thus, the example at the top of this blog.
With Forward Secrecy, every connection to a secure website uses a different encryption key/password.
If a company really cares about security, they use Forward Secrecy. It's not a headline grabbing thing, but many sites use it. Google started using it back in November of 2011 writing at the time "We would very much like to see forward secrecy become the norm..." And, as noted earlier, Apple uses it for their online store.
Without Forward Secrecy, theft or loss of the single password/key lets an attacker decrypt all the prior web pages. Of course, the attacker would have to have been recording those secure web pages, but, spy agencies do so.
Here's the guts of the issue.
Without Perfect Forward Secrecy, Apple only needs to turn over one password/key to the US government to enable the decryption of all Apple IDs and passwords entered on apple.com and icloud.com. The key is just a string of ones and zeros and would probably fit on an index card.
With Forward Secrecy, there is no one single password/key. Secure web pages, even those recorded by a spy agency tapped into the Internet backbond, would remain secure, going forward in time, even if the main password/key was leaked or stolen.
The term Forward Secrecy refers to whether something that is a secret now, will remain a secret going forward in time even if the main key is compromised.
For more on Forward Secrecy see these articles from Qualys, Netcraft, The Register and CNet. All were written in the summer of 2013, shortly after Edward Snowden helped reveal that spy agencies were indeed recording some/much/most Internet traffic.
As for Apple documentation, their iCloud security and privacy overview (Last Modified: May 13, 2016) mentions the transmission of passwords a couple times.
In one place it says that an iCloud username and password is "sent over an encrypted SSL connection" - no doubt relying on the reader to incorrectly assume that all encrypted SSL (it is really TLS) connections are the same. Elsewhere, it says that keychain data is transmitted with 256-bit AES encryption.
What it does not say, is anything about Forward Secrecy, which blows a hole in the cryptography. In effect, the article is bragging about the lock on the front door while leaving out the fact that the key is under the doormat. Penn and Teller would be proud, this type of mis-direction is what magicians depend on.
Why does Apple disable Forward Secrecy when customers enter their Apple ID and password?
Like death and taxes, you can be sure they won't say.
- - - - - - -
Update: September 14, 2016.
How obscure is Perfect Forward Secrecy? The specs for TLS version 1.2, the latest and most secure SSL/TLS protocol, are 100 pages long and mention it only in passing. Here is the first mention
... a compromise of the server's static RSA key results in a loss of confidentiality for all sessions protected under that static key. TLS users desiring Perfect Forward Secrecy should use DHE cipher suites.
and here is the second
... using a fresh key for each handshake provides Perfect Forward Secrecy. Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.