[rfc][icedtea-web] https probing

[Jiri Vanek]

On 08/11/2014 06:11 PM, Jacob Wisor wrote:
> 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.


OK. I was not aware of most of this. This needs much more studying on my side.
>
>> 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.
>

It have sense. Also I have planned something similar, but wonted to have default approach in before 
starting torturing with the dialogues. Also I think there should be possibility for getting  rid of 
this "issue" pernamently. But after reading your posts I agree that simple property is really 
unsafe. So "remember decision for this url" with really strong warning  or the approach you 
suggested in your second email may be the correct middle way.

Still I would like to proceed with general approach before starting with dialogues.
( one for  accepting invalid cert (and one for ssl2?)
> 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.


Well after this I can not not-agree. And I'm probably to lazy to work on administrator-only solution.
>
>> 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.

On one side I agree with you. On second, I'm spammed by "it works with oracle, why not with 
itw?!?!?!?" And if we consider Oracle as killing plugin and javaws then this is really suspicious.

This is one of the main reasons why people - even on linux/open licenses systems still have Oracles 
bob rather then itw:(

>
>> 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. ;-)

ugh. Yes:(


Thanks goes to you!

J.