Oh, just click "yes"

Published: 2011-02-04
Last Updated: 2011-02-04 01:09:56 UTC
by Daniel Wesemann (Version: 1)
5 comment(s)

Java and Java Applets are featuring prominently on my "annoyances list" this year. There are vulnerabilities aplenty, and incompatibilities keep many a firm or university from applying the patches. We've covered these to some extent.

The latest incarnation of annoyance though is commercial software applets that are signed with an expired certificate. Dear vendors, if your "release" is supported until 2013, it is a bad idea to sign the code of said release with a cert that expires in December 2010. And it is an even worse idea to suggest to clients who open a ticket that they should just tell their users to "click yes" on the certificate warning until a patch can be provided.

The Original Sin of certificate handling in Java and Web Browsers alike?

The "oh, connect anyway" button.

I sure wish it simply weren't there.


Keywords: certificate java
5 comment(s)


Wow... just... wow... Almost might as well sign it with a self-signed cert... Wouldn't be surprised if someone thought of an interesting search engine optimization around this, if they knew the product...
I trust self-signed certs that I've seen before more than anything signed by an 'authority'.

The day a browser doesn't let me make that decision myself is the day I stop using it.

A certificate on the web tells you:
The connection to the server is encrypted. It does not guarantee anything beyond that. If you get an e-mail address on a domain, you can get a cert for it.
I am not sure if it is any better with code signing cert. You probably can also get a cert by getting the ssladmin@domain.com.

And of course there is the addition, that some governments has approved root certs, and can play MitM like Tunesia did recently with the help of MS.

Cert management in the real world does not work. The Apple walled carden is better. Here they at least check if code seems to be too bad.

EV certs are better, but still not good.

Best to delete root certs, and add exceptions for the sites you use. Then you will at least get a warning if the site changes cert out of schedule, and can then validate the chain. And avoid IE that just re-adds root certs on its own.
Quote: "A certificate on the web tells you: The conncection to the server is encrypted".

Wrong. If your browser cannot reliably determine (for example by checking the CA digital signature, or by obtaining the cert via a reliable channel) that the hostname and public key provided in the server certificate actually belong to the owner of the URL you're connecting to, then the encrypted channel could end _anywhere_.

I mean the actual intended server but also any device (or even piece of software on your own PC) in between. Or, if DNS is spoofed, any host on the internet.

A digital certificate is worthless if you're not sure that the public key in the certificate corresponds to a private key that is only in the posession of the legitimate owner.
Okay, let's look at this the right way.

If you get a locked certificate with no errors your stream is secure between you and the server you are communicating with unless big brother is in the middle.

The server you are communicating with MAY NOT be the server you think it is, and it may be compromised in other ways. Once your data goes there ALL BETS ARE OFF!

So what if your connection is secure. Is the server open to the world via an exploit? You DO NOT KNOW.

Bottom line... If you send data make sure you have a way to cover your butt when that data gets stolen. It can happen any time and at any point in the connection. It can happen after the fact too.

The lesson.. you cannot trust ANYTHING!


Diary Archives