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

Hello!

Here is updated patch.

One minor - the deployment properites names.


And one mayor - the ssl2 and errornous certificate have to be explicitly enabled in proeprties, and 
even then the user will be again asked.  See, those are todo. The choice remember decision will be 
probably included.


Are you more happy with this double confirmation pattern?

J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpsSolution_02.patch
Type: text/x-patch
Size: 38214 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140818/772d16be/httpsSolution_02-0001.patch>