Hi,
(making this public, I'm 99.99% sure you won't mind since you signed
the proposed patch)
misc@??? wrote (21 Dec 2015 21:10:16 GMT) :
> From: Michael Scherer <misc@???>
> 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
