[rfc][icedtea-web] https probing

[Jacob Wisor]

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

Later this day, I have realized that users can already accept some invalid or 
unverified certificates by importing them into either their user or system 
certificate stores. I say /some/ because certificate stores may not allow 
importing and trusting certificates that do have the 2.5.29.19 OID extension 
CA=true. But the default JKS certificate store seems to be okay with this. So, 
at this point this "fix" is kind of redundant or obsolete.

What could be a benefit indeed would be adding some similar UI to what browsers 
employ to prompt users for accepting/denying invalid or unverified certificates. 
I think this is the direction this patch should be moving along.

Jacob