[rfc][icedtea-web] https probing

Jiri Vanek jvanek at redhat.com
Mon Sep 8 09:44:00 UTC 2014


On 09/08/2014 09:00 AM, helpcrypto helpcrypto wrote:
> Hi Jiri.
> Should i apply/test this patch?
> Does it solve my TLS problems?


Nope. :(


Although thjis patch is base ston for all simialr issues, now is handling only two cases.


Your's one will have to be solved, and later added as probe case.


J.
>
> Regards.
>
> On Wed, Sep 3, 2014 at 4:04 PM, Jiri Vanek <jvanek at redhat.com <mailto:jvanek at redhat.com>> wrote:
>
>     On 08/26/2014 09:51 AM, Jacob Wisor wrote:
>
>         On 08/26/2014 09:16 AM, Jiri Vanek wrote:
>
>             ping?
>
>             On 08/20/2014 08:30 PM, Jiri Vanek wrote:
>
>                 On 08/19/2014 11:25 PM, Jacob Wisor wrote:
>
>                     On 08/18/2014 08:46 PM, Omair Majid wrote:
>
>                         Hi,
>
>
>                         * Jacob Wisor <gitne at gmx.de <mailto:gitne at gmx.de>> [2014-08-11 12:12]:
>
>                             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
>                             <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.
>
>
>                         This isn't SSv2, though. It's a SSLv2 hello packet wrapping an SSLv3
>                         packet: http://bugs.java.com/__bugdatabase/view_bug.do?bug___id=4915862
>                         <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4915862>
>
>                         It's actually part of the TLS 1.0 spec:
>                         https://www.ietf.org/rfc/__rfc2246.txt
>                         <https://www.ietf.org/rfc/rfc2246.txt>, Appendix E.
>
>
>                     This part describes backward compatibility of TLS 1.0 clients to SSL 3.0 and
>                     SSL 2.0 servers (and
>                     vice versa).
>
>                     "TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
>                          Version 2.0 client hello messages [SSL2]. TLS servers should accept
>                          either client hello format if they wish to support SSL 2.0 clients on
>                          the same connection port. The only deviations from the Version 2.0
>                          specification are the ability to specify a version with a value of
>                          three and the support for more ciphering types in the CipherSpec."
>
>                     Currently, IcedTea-Web is a TLS 1.0 or SSL 3.0 client. According to this
>                     paragraph, TLS 1.0 clients
>                     send SSL 2.0 client hello messages in order to connect to SSL 2.0 servers,
>                     that is, to negotiate a
>                     SSL 2.0 connection. So no, SSL 2.0 servers do not upgrade automagically to
>                     TLS 1.0 when they receive
>                     SSL 2.0 client hello messages from TLS 1.0 clients. Pure old SSL 2.0 servers
>                     will never speak
>                     anything later than SSL 2.0.
>
>                     One reason behind this paragraph was for TLS 1.0 clients to allow probing SSL
>                     2.0 servers with
>                     cipher specifications in SSL 2.0 and those introduced in TLS 1.0. In
>                     practice, SSL 2.0 servers will
>                     _never_ negotiate to a cipher specification introduced since TLS 1.0 because
>                     they were simply not
>                     built for that.
>
>                     Another reason for this paragraph back in 1999 (!) was to allow implementors
>                     of TLS 1.0 to ease
>                     transition from SSL to TLS and to give them the option to merge TLS into
>                     their existing SSL
>                     libraries (or as much as possible build on top of them). Again, this has
>                     nothing to do with
>                     automagically upgrading SSL 2.0 servers to TLS. It is just a description of
>                     how TLS 1.0 clients
>                     could fallback to SSL 2.0, if they wish to.
>                     And, I am most certain nobody should want this, unless one has no clue what
>                     transport security is
>                     all about or is a complete lunatic.
>
>                     The next paragraph says it all:
>
>                     " Warning: The ability to send Version 2.0 client hello messages will be
>                                  phased out with all due haste. Implementors should make every
>                                  effort to move forward as quickly as possible. Version 3.0
>                                  provides better mechanisms for moving to newer versions."
>
>                     So, the Java API should have got rid of the option to fallback to SSL 2.0
>                     years before. It's a shame
>                     that J2SE still supports SSL 2.0 connections in 2014. Why? Because this has
>                     nothing to do with
>                     compatibility but with *security*.
>
>
>                 Ok. Thank you for patience with me. (really!)
>
>                 So there is another approach.
>
>                 Now the ssl2 is tested as last attempt, and if it is possible to connect like
>                 that, then the user is
>                 warned and error is thrown (which leads to skipping resource from that
>
>
>                 The not-checking certificate now can be allowed or forbidden by properties. By
>                 default it asks user
>                 by every such invalid certs its found. How to deal with human intraction is todo.
>
>
>                 The reason for this message is to get verbose logical error emsssage, not only
>                 "itw do not work again"
>
>
>                 What do you think now?
>
>                 J.
>
>           >
>           > +                        DeploymentConfiguration.KEY___HTTPS_PROBINGALOWED,
>           > [...]
>           > +    public static final String KEY_HTTPS_PROBINGALOWED =
>           > "deployment.security.https.__probing.alowed";
>           > [...]
>           > +    public void disconect(URLConnection conn) {
>           > [...]
>           > +    public synchronized void disconectHttps(__HttpsURLConnection conn) {
>           > [...]
>           > +        private final boolean unsecure;
>           > +
>           > +        private HttpsSettings(boolean ssl2, boolean unsecure) {
>           > [...]
>           > +        public static URLConnection openConnection(URL url, boolean ssl2,
>           > boolean unsecure) throws IOException {
>
>         I am not testing this unless you have fixed your typos.
>         For god's sake, your are a programmer, right? You should know best that exact spelling is
>         important.
>         Obviously, I am just talking till I am blue in the face.
>
>
>     Noooo. I moreover overlooked :( Sorry.
>
>     Now it should be as good as I'm able to do so without third party attendance.
>
>
>         Also, please replace all occurrences of "ssl2" in text strings with "SSL2" (or "SSL 2.0" as
>         used in
>         the specification). Acronyms of names are always upper case in English.
>
>
>     ok!
>
>
>
>
>     Here is updated version.
>
>
>     Sorry for delay, I was hacking the documentation generator. Now its one (discussing with Lukas
>     concurrently edited code), ad I think you will like it :)
>
>
>     J.
>
>
>



More information about the distro-pkg-dev mailing list