[rfc][icedtea-web] https probing

[Jiri Vanek]

On 08/18/2014 08:27 PM, Jacob Wisor wrote:
> 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_ALLOWINSECURE
>
>> +                        DeploymentConfiguration.KEY_HTTPS_ALOWSSL2,
>
> DeploymentConfiguration.KEY_HTTPS_ALLOWSSL2
>
> 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.
>

/me on netbeans


But yes. NB have also some spell checker, but they do not check connected words. Exactly those you 
suggested.

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

As Omiar explained, it is only handshake. I should be more specific. But the code "ssl3ssl2Hello" or 
messages with "handshake"  seemed to be at least a bit self explaining. Sorry for not being enough,
>
> 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.


As I see it after this suggestion, is to have :

deployment.security.https.allowunsecure
changed to
deployment.security.https.invlidcertificates.trust=yes|no|ask
where yes will proceed without asking
no will die without asking
and ask (default) will ask for this particular case. The implementation of dialogue is todo for 
another patch, and necessary before 1.6 release.

And whether it will be an record in extendedAppletsSecurity or added certificate sto store. it can 
be decided later.  I'm currently for first option. As I don't like addition of invalid certificate 
to global store.
>
>> 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.

Well it was changed  - Before you could disable it by single line, now you need to enable by single 
line before before you can actually proceed to human approve. This human approve is TODO. But before 
I proceed to that, I wont initial concept done.

As I understand, the to-simple-allowance was your second greatest concern.

J.