As part of its SSL Observatory project, the EFF has found that tens of thousands of SSL certificates have been issued for nonsense domains, something that should be impossible. It indicates certificates are being issued without necessary checks taking place.
Most of us are aware of the padlock system by which we know if a connection to an online bank, shop, or webmail provider is secure. The Website address is also prefixed by https://, which provides another clue.
The system relies on the remote Web server sending your browser its public SSL certificate. Via a handful of cryptographic transactions, your browser is able to use this to verify the remote server is who it says it is, and that you're not connected to a fraudster. It is also able to encrypt data transmissions.
Therefore, the authenticity of the SSL certificate is of prime importance. It's because of this that the number of companies worldwide that issue certificates, known as Certificate Authorities (CA), is strictly limited.
A variety of SSL certificates can be purchased. With very basic SSL certificates the CA checks to ensure the company is the same one that registered the domain. With more rigorous certificates, such as the Extended Validation Certificate that most reputable organizations use, the CA is required to prove the physical location of the company in the real world, amongst more stringent investigations. It's for these reasons that purchasing an SSL certificate can be expensive.
If a CA issued certificates for simple, single words such as "mail" or "Web," it would indicate their checking procedure isn't up to scratch because these are not real Internet addresses. Yet this is what the EFF has discovered. It found 37,244 examples of certificates for ‘unqualified' domain names, which is to say, general words or terms that are simply meaningless on the Internet and should never have had certificates issued for them.
The problem is largely caused by corporate network administrators. They purchase SSL certificates for words like "mail" and "Web" to create secure connections between computers on their internal networks (known as Intranets). Rather than having workers type mail.mycompany.com into their browsers to access the corporate mail server, for example, a network administrator might configure the network so users type "mail."
But to make connections secure from networking snoops, the admin will purchase an SSL certificate for the computer the word "mail" directs to. Attempting to buy such a certificate would be impossible if the CA performed the most rudimentary examination of the request and realized it's not a real domain.
Perhaps more worrying, further research shows CAs are also issuing certificates for words involving non - real top - level domains (TLDs). TLDs are the endings of Web addresses and examples include .com, .org, .net and so on. The EFF found that certificates were being issued for nonsense words joined to made-up TLDs like .nyc, or .public. Again, these are likely used within corporate environments to indicate an attribute or location of a server. For example, "mail.nyc" might indicate a mail server based in New York City. The address "web.private" might indicate a non-public Web server.
Let's assume that the .nyc TLD is one day created and a guy registers "mail.nyc." He's got a problem because whoever has already been issued a certificate for "mail.nyc" by a CA that didn't perform checks will be able to hijack visitors to his site, seemingly providing a 100 percent trustworthy connection.
Taking advantage of the careless certificate authorities, right now hackers could purchase certificates for any likely future combination of domain plus TLD. How about getting a certificate for "web.apple," for example, in anticipation of a time when Apple gets its own top-level domain? Hackers could then hijack any user who types https://web.apple into a browser, and it wouldn't appear to be anything but legitimate.
Aside from suggesting that certificate authorities do their job properly, the EFF suggests that browsers and other Internet software could only accept SSL certificates for genuine (fully-qualified) domain names. After all, it should be impossible for a connection to take place to something like "https://mail," yet browsers don't check for such transgressions (as anybody who's mistyped an address will know).
The SSL certificate system has been under significant attack recently. A hack attack on one of the biggest certificate authorities has brought into question the entire system and made many realize that the system is in drastic need of updating for 21st century demands. At the moment there are over 600 certificate authorities around the world that major browsers trust--that is, Internet Explorer, Mozilla Firefox, and so on.
Each CA issues certificates based on variations of local laws plus their own peculiarities. As with any collection of organizations, some are better than others, both in their criteria for issuing certificates and also their internal security procedures that stop hackers infiltrating their systems and fraudulently issuing certificates.
Ultimately, all of this means that we can no longer fully trust HTTPS connections. However, until schemes like DNSSEC come online, we simply have no choice but to do so. Keeping common sense with us at all times will help. If you visit your bank's home page, for example, and they suddenly seem unable to construct proper sentences, then there might be something wrong.