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 |
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 |
Free forum by Nabble | Edit this page |