[rfc][icedtea-web] https proobing

[Jiri Vanek]

Hi!

this patch *should* solve most of the issues ITW have with various broken or old https servers. 
Should, because I have no page where to reproduce. My only tracker is 
https://bugzilla.redhat.com/show_bug.cgi?id=1089130 and small attached program which I wrote used to 
tests various requests to known broken https server (to get files).

The patch do following:

Wrap all url.openconnections and connection.dieconet by wrapper.

This wrapper do following:
if connection is not not https, it acts as before (except only synchronized disconnect)
if it is https, it locks other (https) connections and  tryes server:
  -  if it is not using old handsake or invalid certificate
  - save those settings
  - all other https connections then uses those settings (unless overwritten)
  - except https openconnection and all disconnect connection  all connectins are parallel  as we 
were used to (unless overwritten)
  - the probing connection is reused (if successful)


The default schema is not working in (rare) cases when resources are in differently "broken" https 
servers. To control this flaws there are 4 properties, which deserves 4 checkboxes in itw-setting 
(another patch onc ethis is agreed)

+    public static final String KEY_HTTPS_PROBINGALOWED = "deployment.security.https.proobingalowed";


By default true, probing is allowed.  If set to false, then itw will behave as before, except 
synchronized disconnect

+    public static final String KEY_HTTPS_SYNCFORCED = "deployment.security.https.syncforced";

by default false. Once true this will disable our excelent paralelism for https downloads. Have 
sense only with  probe always

+    public static final String KEY_HTTPS_PROBEALWAYS = "deployment.security.https.probealways";

when this is true,  each connection will do its own probing. So each can have different https 
settings. Have sense moreover onl with syncforced, otherwise exisitng conections will overwite each 
other and fail.

+    public static final String KEY_HTTPS_ALOWUNSECURE = "deployment.security.https.allowunsecure";

This is actually creating security hole. SO by default false. Once in itw-settings, it will need 
strong warning for user. It disables certificate verification.



hmm..During writing of this email I have realized that I can use same synchronized trick as for open 
connection (synchronize once https is recognized, but let http be). The patch is updated. But I have 
not tested. I guess I will test it during next iteration. This is justnote for reviwer that if you 
will encounter any flaw in above description, this is probably cause. And so above "synchronize 
ddisconnect" is now valod only for https.


J.

ps: this patch is unbackportable :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OnOffSSLv2UntrustedCerts.java
Type: text/x-java
Size: 5635 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140807/8eaaa850/OnOffSSLv2UntrustedCerts-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpsSolution_01.patch
Type: text/x-patch
Size: 37492 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140807/8eaaa850/httpsSolution_01-0001.patch>