[Captivate Android Development] littlewierdo:
Ok, some brief information on what this SSL thing is and how it works in laymans terms.

SSL (short for Secure Socket Layer) is an internet protocol all supporting web clients use to create a 'secure' connection to a web page. You know you are connecting via SSL if your web address changes or includes https:// at the beginning of the web address rather than the standard http ://.

In addition, many browsers have additional graphics that change when you go to a 'secure' web page.

When you connect to a 'secure' web page (aka SSL or https), a certificate (a small file with various check sums) are swapped between your PC and the host PC (or server) you are connecting to which serves the purpose of authenticating the host PC (in other words, verifying you the user are connecting to the website you should be).

These certificates are encrypted using public/private key encryption.

For information on what public/private key encryption is and how it works, here is a couple of laymans explanations of it.

http://www.livinginternet.com/i/is_crypt_pkc_work.htm

http://en.wikipedia.org/wiki/Public-key_cryptography

This certificate is provided by various providers such as Verisign, GoDaddy, Equifax, etc (there are TONS of providers for these certificates) at a cost ranging from a hundred dollars (USD) all the way to over a thousand dollars (USD) per year (the cost is for most typical situations). These companies that provide the certificates are commonly referred to as certificate authorities.

The certificate authority that provides these certificates can choose how much verification they want to do on said company, ranging from simply verifying the business address, verifying the phone number, verifying employees, credit checks on the company or its owner(s), etc. It simply depends on which certificate authority the business decides to get its certificate from.

So, here is a brief synopsis so far, we will use Google as an example.

1. Google obtains a certificate from a certificate authority called Digicert and implements this cert (or in the case of Google, multiple certificates from Digicert) across their various websites and platforms.

2. Web browsers and OS manufacturers are informed of these certificates (and any changes made to these certificates) and maintain a file on your Windows/Mac/Linux/Android/Other OS device that define what certificates they should accept. In the case of the PC, both Internet Explorer and Safari (for windows) use the default information that comes from your Microsoft installation (which is updated via MS updates) where-as Firefox and Chrome both use their own database for managing the certificate authorities.

3. You (the user) signs into Google to check your email by typing in ' http://www.gmail.com '. Google detects that your browser and device have the capability of performing a more secure connection and Google re-routes you to 'https://mail.google.com' (note, the http was changed to https).

4. Your browser then receives a certificate from Google that is digitally signed using public/private key encryption and is decrypted and verified, if necessary, multiple certificates may be required to verify depending on how much information from the web page you are visiting is secure and whether it is coming from multiple sources.

Now, here is what the vulnerability is. A company that receives a certificate is responsible for maintaining their own private decryption keys and not to allow these to get out into unsafe hands. In this day and age, that can be very tricky because of the internet and company sizes (who is to stop someone who 'looks' professional from just walking thru the front door and finding an empty cubicle).

The certificate providers are also responsible for maintaining and keeping the keys they use to generate keys for their customers.

'If' a company looses control of their certificates, this allows any hacker with 2 brain cells to forge any certificate they wish and make it 'appear' that users are connecting to a valid website with a valid connection, when in fact they are not.

Here might be a typical example:

1. User types in 'www . gmall . com. Note, first, I put spaces in between the dots. This is so that someone doesnt click a link as they are reading this. Secondly, note that 'gmail' is mispelled with 'gmall'.

2. The user is presented with a login screen that looks JUST LIKE the standard gmail screen. The user 'forgets' to verify the web address but notices that they are connected with a valid certificate. They look at the certificate to verify everything looks good and continues by inputting their email address and password to login.

Voila! The hacker now has full access to your Google account. This by the way is your entire Google account, not just your email.

Good security includes at least two forms of authentication - something you know and something you have. In the case of secure web pages, the 'something you know' part is your username and password. The 'something you have' part is where the certificate comes into play. Two forms of id.

So, this vulnerability that all browsers and OS's had to update for basically are because a Dutch company called Diginotar (a certificate authority) had the private keys they use to sign their certificates stolen. This allows any hacker with those keys to 'pretend' to be ANY website they want to be (but only if that website was signed by Diginotar originally). Diginotar is a BIG provider of certificates in Eastern countries, and, coincidentally, multiple certificates for Google, including their Gmail certs.

The update essentially removed the certificates that are known to have been stolen from Diginotar so that your browser simply does not accept a certificate if it is signed with the known stolen key. SSL (https) protocol handles this by simply dropping the connection and not allowing the browser to connect to the site if the certificate is bad (technically, this depends on how your browser is configured - at a minimum, the user would be informed of a problem, often times in very cryptic and confusing language).

http://en.wikipedia.org/wiki/DigiNotar

Now, this 'really' long winded explanation is a 'brief' overview of how internet security works. I STRONGLY suggest that everyone who made it this far should listen to the Security Now podcast available on www.twit.tv/sn.

Hosted by Leo Laporte and co hosted by Steve Gibson (one of the few programmers who program in strict assembly language and a man I have HUGE respect for), this podcast covers EVERYTHING security related in a digital world. They currently are at over 350 episodes (it has been on for 6+ years now). It is a weekly podcast, about 90 minutes per episode and they covered the Diginotar incident in great detail.