[rfc][icedtea-web] https probing

[Jacob Wisor]

On 08/08/2014 10:37 AM, Jiri Vanek wrote:
> Unluckily this fix patch is not helping obscure servers to do exists. It really
> fixes bugs.
>
> First part of fix is delivered to be able  handle SSLv2 handshake, Those servers
> do exists, and have no reason nor need to update or patch or whatever. We are
> wrong by not allowing it right now.
> See   System.setProperty("https.protocols", "SSLv3,SSLv2Hello"); in code.

Oh yes they do need fixing. SSLv2 is insecure and has been revoked by the IETF, 
period. Nobody should be using it. Even SSL 3.0 is deemed by the IETF as 
historic (https://datatracker.ietf.org/doc/rfc6101) although it is largely 
identical to TLS 1.0. Nevertheless, nobody should be using it either. Just one 
of many reasons is that it does not even support such a common hash algorithm as 
SHA1 (which by the way has been deprecated by NIST in favor of SHA256 too). 
Everybody should really upgrade to at least TLS 1.0, even though possible 
security leaks have been discovered in TLS 1.0 on specific configuration 
settings permutations.

DO NOT use SSL anymore and DO NOT promote them in your software. Upgrade to TLS.

> Second "fix" to skip certificate check - yes it is workaround abut servers
> fault. But imho necessary workaround. From time to time nearly each server
> corrupt/*outdate* (read not refresh in time ) theirs certificares . Yes it is
> always flaw of admins, but if I insists on usage of javaws/applet in this period
> before admins fix? Then I'm screwed with itw now. Unluckily in intranet
> environment (all https bugs I had were actually reported form intranet) this is
> really common. As another changeset I will probably add warning for "untrusted
> https forced" or similar.

Really? You really want to /enable/ skipping certificate verification just by 
the blink of one switch? Have not we learned anything from the past certificate 
fiascos and the most recent one "Fake ID" in Android?

I am not totally against /accepting/ invalid certificates or certificates which 
validation does not work out but am against doing it in a dump automated way. 
For example, most browsers enable users to /accept/ invalid certificates per 
session or per website which is okay. But please note that they only do so after 
first warning the user and then the user is forced to deliberately take action 
to accept an invalid certificate. This is not the case with this patch.

The only automated approach I would accept is where the *administrator* (root), 
not the common user, can setup a system setting for IcedTea-Web (e.g. in 
/etc/icedtea-web.properties) with a list of accepted SHA1 or SHA256 (or other 
has algorithms) certificate hashes. Any other approach would be grossly 
negligent, not to mention idiotic.

> Nevertheless, proprietary javaws/plugin must be doing something similar, because
> they do not have similar https issues. So we *must* handle them (not necessary
> by this patch, but I have not found another way in weeks of investigating).
> Maybe it is messing the concept a bit, but if it is not fixed, then people will
> always say "it is working with proprietary one" and so get rid of itw.

Just because someone else is jumping out the window, it does not oblige us do so 
too.

> As for naming suggetstions:
> I would vote for
>
> deployment.security.https.probing.alowed
> deployment.security.https.syncforced";
> deployment.security.https.probing.always";
> deployment.security.https.allowunsecure";

Please, the term "unsecure" does not exist in the English language. Luckily, the 
term "insecure" does. ;-)

Have nice day!

Jacob