Hi, (making this public, I'm 99.99% sure you won't mind since you signed the proposed patch)
[email protected] wrote (21 Dec 2015 21:10:16 GMT) : > From: Michael Scherer <[email protected]> > Since TLS v1 could be attacked (since that's SSL v3), it is better > to use the latest crypto algo. > --- > config/chroot_local-includes/usr/local/sbin/htpdate | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > diff --git a/config/chroot_local-includes/usr/local/sbin/htpdate > b/config/chroot_local-includes/usr/local/sbin/htpdate > index 5c0b70b..678480f 100755 > --- a/config/chroot_local-includes/usr/local/sbin/htpdate > +++ b/config/chroot_local-includes/usr/local/sbin/htpdate > @@ -221,7 +221,7 @@ sub getUrlDateDiff { > my @curl_options = ( > '--user-agent', $useragent, '--silent', > - '--proto', '=https', '--tlsv1', > + '--proto', '=https', '--tlsv1.2', > '--head', '--output', catfile($tmpdir, 'headers'), > ); > push @curl_options, ('--socks5-hostname', $proxy) if defined $proxy; Thanks for caring, and sorry for the delay. (Hint: going through Tails discussion channels helps avoid the bottleneck that my inbox is. It doesn't always work, but it's worth trying :) I'm divided about this proposed change. I acknowledge it would improve things *now*. OTOH it might prevent us from benefiting from upstream default settings improvements. E.g. once TLS 1.3 is out, then we get it for free if we stick to --tlsv1, while we would not get it if we hard-code --tlsv1.2. Past experience has proven that we're quite bad at maintaining our smart ass attempts at hardening default crypto settings beyond the obvious, so I'm somewhat warry of going this way again. FWIW, I would feel totally differently about it we had for example: * a centralized list of all places where we hard-code such crypto settings that deviate from upstream defaults, with some minimal justification (I could help build the initial list, but won't maintain it nor provide the patch against our design doc that puts the list in there); [somewhat OT: my secret hope is that said justification helps convince upstream to change their defaults, in some cases; my top-secret hope is that dkg handles bringing the case upstream whenever it makes sense] * a lightweight process to check if our custom settings still make sense, say every year and whenever we switch to a new Debian release * some volunteers to turn all these fancy ideas into action Cheers, -- intrigeri _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
