[rfc][icedtea-web] https probing

Jacob Wisor gitne at gmx.de
Mon Aug 18 18:27:24 UTC 2014

W dniu 18.08.2014 14:16, Jiri Vanek pisze:
> 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.
> +                        DeploymentConfiguration.KEY_HTTPS_PROBINGALOWED,

Still, you really have to check your spelling! :-\
It is DeploymentConfiguration.KEY_HTTPS_PROBINGALLOWED

> +                        DeploymentConfiguration.KEY_HTTPS_ALOWINSECURE,


> +                        DeploymentConfiguration.KEY_HTTPS_ALOWSSL2,


You know, Eclipse has a really cool feature built in to help you with this. It 
is called "spelling checker". ;-) You can find it under 
Window/Preferences/General/Editors/Text Editors/Spelling. Since it eats up some 
quite considerable amount CPU cycles when typing into the editor, you do not 
need to have always on. Please run it least when your done.

Btw, e-mail clients tend to have sophisticated "spelling checkers" too. Believe 
me, it is a pleasure for readers confront them with texts free of spelling errors.

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

No I am strictly against any option which allows downgrading security to SSL2. 
SSL2 is *BROKEN*, period! Broken security means NO SECURITY. There is nothing in 

Invalid or unverified certificates is something different. Why? Because we 
cannot and should not make anybody trust any specific certificate on terms we 
deem as appropriate. Automated verification of certificates via certificate 
chains against a root CA as provided by browsers, Java, and so on, is primarily 
just a feature to relieve the user of the length, complex, error prone, and 
tedious task of doing it himself. It just helps to automate the chain of trust, 
nothing more nothing less. Everybody is free to trust any certificate they are 
presented, no matter whether an automated signature and hash verification turns 
out to be right or not. So, this actually does not need a global option. If a 
certificate - for what ever reason - cannot be verified, we can /always/ ask the 
user if he/she still wants to trust this certificate anyway. Nevertheless, I 
agree that deployment scenarios do exist where administrators may want to 
restrict this option to their users. So, we should be actually only providing a 
negative global option: Do not accept invalid or unverified certificates? If the 
administrators says yes to this, no user will ever be asked if he/she wants to 
trust an invalid or unverified certificate. This should be enough for about 
every scenario.

To make it more clear what sets these two aspects apart is the simple fact that 
SSL2 can and has been proved to be broken. Where as with invalid or unverified 
certificates no /general/ proof can be made about their trustworthiness because 
it depends on a set of preconditions which are only valid to every specific user.

> Are you more happy with this double confirmation pattern?

No. Asking the same question twice while no state change incurs over time 
pertaining to the question, will not change the answer to to the question. So, 
it it useless and senseless to have double confirmation in place.


More information about the distro-pkg-dev mailing list