2015-08-13 18:24 GMT+02:00 Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx>: > On Thu, Aug 13, 2015 at 06:10:48PM +0200, Elia Pinto wrote: >> 2015-08-13 18:01 GMT+02:00 Torsten Bögershausen <tboegi@xxxxxx>: >> >> + >> > from >> > https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0 >> > sslv2 and sslv3 are deprecated. >> > Should there be a motivation in the commit message why we want to support them ? >> They are those provided by the documentation (TLS in particular). We >> let the underlying library to say what is deprecated or not. In this >> case the call fail. > > The statement from the relevant SDO is much stronger than "deprecated", > it is "not to be used under any cirmumstances". > > Option like this looks only useful for connecting to really broken > servers, damn security. I know very well this topic. https://securitypitfalls.wordpress.com/2015/07/29/july-2015-scan-results/ I prefer that the decision is from the libray not us. > > It could be useful for connecting to buggy servers after TLS 1.3 > comes out and is implemented, as there are lots of servers (IIRC, on > order of 10%) that can't deal with TLS 1.3 properly (but very few, IIRC > <<0.1%, that can't deal with TLS 1.2 correctly[1]). > > Also, is this option settable globally for all HTTP servers? One > definitely does not want that to be possible. Configurations like > this need to be per-server if they exist at all. > > > > [1] Where correctly includes secure downnegotiation, as TLS > is intended to do when faced with version mismatch. > > > -Ilari -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html