SSL vs TLS (Was: Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL vs TLS (Was: Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error)

mkobetic
FYI, this is a nice explanation why just doing what web browsers do when dealing with failing version negotiation, may not always be the best fit for all circumstances:
        http://www.educatedguesswork.org/2012/07/problems_with_secure_upgrade_t.html

[hidden email] wrote:

> Date: July 16, 2012 12:49:45 PM
> From: [hidden email]
> To: "Terry Raymond"<[hidden email]>
> Cc: "'Boris Popov, DeepCove Labs'"<[hidden email]>, "'VWNC List'"<[hidden email]>
> Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
>
> "Terry Raymond"<[hidden email]> wrote:
> > I guess I should ask, how badly broken is it? I am currently upgrading our
> > application and we use SSL and HTTPS. I would really like to use 7.9 as it fixes
> > several problems.
>
> Depends on what you're talking about, VW or the Interwebs. These issues arose primarily because the new TLS supports more than just SSL 3.0 and there are servers and other networking hardware out there that don't handle these correctly. In some large scale tests the number of these broken endpoints was somewhere around 5%, and it should be improving as the web upgrades to better implementations, but it's still significant enough.
>
> At this point the assumption is that the old SSL can handle more sites. That is largely because it simply avoids whole classes of problems by not supporting TLS, you can configure the new TLS stuff the same way as well (note that there are other less aggressive work-arounds which could be more suitable, e.g. some servers are willing to do newer protocol versions but are allergic to extensions, etc. this is all tunable with the TLS configuration). We hope to make some changes that may reduce the need for such drastic work-arounds. Some may actually belong to the higher level HTTPS frameworks rather than TLS, we'll see.
>
> Note that dropping the protocol version is actually the primary "solution" to these problems that the web browsers employ as well. They try connecting with the best options, they fail, they analyze the error then dial back the protocol version and possibly other options and try again. They probably cache their previous results for specific websites as well. I'm not sure that we can be similarly aggressive with a general purpose TLS framework (maybe more so in the higher HTTPS layers)
>
> That said, we certainly can allow for more protocol lenient configurations and such. There were still other cases that we do not understand yet. One of those, that Boris pointed out, was www.buydomains.com, which started working since then, but presumably there will be others like that. Ultimately it boils down to what Boris alluded to. You need to try the sites you need to reach and see. In most cases they should work fine. If they don't then there's the question of what's broken, Boris' links discuss several of these scenarios. Note that it can be quite difficult to figure it out and may requires substantial knowledge of the protocol, I'd suggest simply pointing such site out in this list here or to our support and we'll take a look at what's going on. There are different ways to work around these cases by configuring our TLS end differently to avoid the issue.
>
> In short, there likely are changes we can make to make VW more resilient when interacting with these (arguably broken) implementations, but calling our TLS broken because of this doesn't paint entirely accurate picture.
>
> Martin


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: SSL vs TLS (Was: Re: [now vw7.9] msvcr100.dll Re: vw7.864-bit onwindows error)

Boris Popov, DeepCove Labs (SNN)
Martin,

Indeed, although a set of resumable exceptions (if you want to err on
the side of security) or notifications (for more OpenSSL-like behavior)
could be used whenever the trickery is invoked on the client side to let
framework users decide which conditions they wish to allow,

- speaking to a partner API to transmit sensitive data, one could be
very strict about the negotiation parameters
- speaking to a set of arbitrary callback URLs to transmit non-sensitive
data, one could be very lax about negotiation parameters

-Boris


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of [hidden email]
Sent: Tuesday, July 17, 2012 9:19 AM
To: 'VWNC List'
Subject: [vwnc] SSL vs TLS (Was: Re: [now vw7.9] msvcr100.dll Re:
vw7.864-bit onwindows error)

FYI, this is a nice explanation why just doing what web browsers do when
dealing with failing version negotiation, may not always be the best fit
for all circumstances:
       
http://www.educatedguesswork.org/2012/07/problems_with_secure_upgrade_t.
html

[hidden email] wrote:
> Date: July 16, 2012 12:49:45 PM
> From: [hidden email]
> To: "Terry Raymond"<[hidden email]>
> Cc: "'Boris Popov, DeepCove Labs'"<[hidden email]>, "'VWNC
List'"<[hidden email]>
> Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
onwindows error
>
> "Terry Raymond"<[hidden email]> wrote:
> > I guess I should ask, how badly broken is it? I am currently
> > upgrading our application and we use SSL and HTTPS. I would really
> > like to use 7.9 as it fixes several problems.
>
> Depends on what you're talking about, VW or the Interwebs. These
issues arose primarily because the new TLS supports more than just SSL
3.0 and there are servers and other networking hardware out there that
don't handle these correctly. In some large scale tests the number of
these broken endpoints was somewhere around 5%, and it should be
improving as the web upgrades to better implementations, but it's still
significant enough.
>
> At this point the assumption is that the old SSL can handle more
sites. That is largely because it simply avoids whole classes of
problems by not supporting TLS, you can configure the new TLS stuff the
same way as well (note that there are other less aggressive work-arounds
which could be more suitable, e.g. some servers are willing to do newer
protocol versions but are allergic to extensions, etc. this is all
tunable with the TLS configuration). We hope to make some changes that
may reduce the need for such drastic work-arounds. Some may actually
belong to the higher level HTTPS frameworks rather than TLS, we'll see.
>
> Note that dropping the protocol version is actually the primary
> "solution" to these problems that the web browsers employ as well.
> They try connecting with the best options, they fail, they analyze the

> error then dial back the protocol version and possibly other options
> and try again. They probably cache their previous results for specific

> websites as well. I'm not sure that we can be similarly aggressive
> with a general purpose TLS framework (maybe more so in the higher
> HTTPS layers)
>
> That said, we certainly can allow for more protocol lenient
configurations and such. There were still other cases that we do not
understand yet. One of those, that Boris pointed out, was
www.buydomains.com, which started working since then, but presumably
there will be others like that. Ultimately it boils down to what Boris
alluded to. You need to try the sites you need to reach and see. In most
cases they should work fine. If they don't then there's the question of
what's broken, Boris' links discuss several of these scenarios. Note
that it can be quite difficult to figure it out and may requires
substantial knowledge of the protocol, I'd suggest simply pointing such
site out in this list here or to our support and we'll take a look at
what's going on. There are different ways to work around these cases by
configuring our TLS end differently to avoid the issue.
>
> In short, there likely are changes we can make to make VW more
resilient when interacting with these (arguably broken) implementations,
but calling our TLS broken because of this doesn't paint entirely
accurate picture.
>
> Martin


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc