From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 18 Jul 2016 15:08:03 +0200
Message-ID: <1735315.hXCMA8agXV@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.6.3-300.fc24.x86_64; KDE/4.14.20; x86_64; ; 
 )
In-Reply-To: <20160718130843.0320d43f@pc1>
References: <20160718130843.0320d43f@pc1>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2311106.RTmiUEvLIW";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FKFPX1NazH3Dak-AbRYUG6TiEP8>
Subject: Re: [TLS] Thoughts on Version Intolerance
Precedence: list

--nextPart2311106.RTmiUEvLIW
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Monday 18 July 2016 13:08:43 Hanno B=C3=B6ck wrote:

> * There don't seem to be any straightforward tools that test for
>   version intolerance. The SSL Labs test does detect version
>   intolerance, but it's limited to public facing https servers and it=

>   doesn't seem to detect some of the weirder variations (as described=

>   above). There's also a test in Hubert Kario's tlsfuzzer, but I've
>   been unable to get it to work. I tried to create a test myself, but=

>   the results were highly erratic and I'm not sure why.

I hope that the updated README helps about this (just pushed the change=
s),
tell me if anything else is missing

feel free to send the problems with the test you wrote yourself
(but please remember, the note in README applies - it's an alpha, so
no API stability guarantees)

> * We don't have good data on the issue. The latest numbers I could fi=
nd
>   came from Ivan Ristic in 2013 [4], and from David Benjamin we know =
he
>   considers the problem to be large enough that version fallbacks are=

>   inevitable. That's far from good data. We also don't seem to have a=
ny
>   public list of affected vendors, devices and webpages.

I'm running a test against the Alexa Top 1 million /right now/ using th=
is
code:
https://github.com/jvehent/cipherscan/pull/109

In general it's a rough check, i.e. it's only a check for client hello
version intolerance, irrespective of record layer version, ciphers or
extensions (it sends multiple probes, based on different clients and
then modified)

I've also added an Xmas-client hello message[1] that aims to trigger as=

many intolerancies as possible, but it's mostly just to single out
some weirder servers.

e.g. some servers will just close connection if you send them an SNI
name they don't expect

 1 - similar to https://en.wikipedia.org/wiki/Christmas_tree_packet

> I want to try to work on some of those issues in the near future.
> Roughly I'd like to see that we work on a plan to reduce TLS brokenne=
ss
> in general and in particular - right now as this is an issue affectin=
g
> the deployment of TLS 1.3 - Version intolerance.
>=20
> Things that I think we could and should do:
> * Talk to developers of test tools (sslyze, testssl, openvas, but als=
o
>   commercial tools etc.) that they include appropriate tests in their=

>   tools and warn about these issues. Also it'd be great if e.g. thing=
s
>   like the google webmaster tools or any other public test tools for
>   webservers/websites could test for this.

+1, especially TLS 1.3 client hello version intolerance should be
an outright failure of any TLS test

> * Get some data from internet wide scans and make it public. Maybe ha=
ve
>   a public shame list of the top X pages breaking TLS.

I'm working on it. I'll make the scan data public, but I'll leave the
shaming part to somebody else

> * In general, more and better detailed documentation of this and
>   similar issues, also raise this as a potential research topic.

+1 again, I think we should do a more "negative" reading of the TLS sta=
ndard
(as in what the peer should do if the other side does not behave as
expected) both to specify what alerts should be sent, when, and when
such "misbehavior" MUST NOT trigger any failure in the other side

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi=
c
--nextPart2311106.RTmiUEvLIW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJXjNSzAAoJEJKo0bgB0vX18TcP/RnwWwiPIW6kk5JJ3UjnBYq7
wlNws21moRdyhvWUcOzFF5liJsucs5QJ8je8HcZ4x0sf9KpNV1ofZOP59ABJ0gnC
5TBn37oXHJHnzB5mWQOWv5CS17KPfIwYqlzjsYcEEvYhBc0x3/z8hJApZyeQGXeF
q9X8F7ecK1jvlfHVcxrYwUukAbI3xJKxbd2L3X+jJEbI+K42GdoeoBQMOb4NNnpZ
kEldwCerDRQBD4V4naD/u3zhd8HEYZQl1ZVhqbIE1ckuRB3+4VXFY0eBuL49oint
6xftLllDOGIUT/vfOHdEc/MhAsbHYxA5+mKLezsGeSRfH251vsRSJbPwoqOPa3s+
jL06R5a6e7ouyvOw0Seq2vLVuM4bNVw/AE/06owCLXbM6ODUqbt1HFFJXeUNIJPC
1gMivy1mPa+1yTbw3RHGWO1C0jl0jRID7tb+V0Y/WBYDh2FGLosr0ytz5sa9aUBJ
oJXzzs7PWeyNVQIxsz5eKyvgEYcjc7STHiIgFWUncwH47Tm97RL+l100jSwoPnJl
8x8I19U6tvuHGxCFnBXINc2GK9+9HVbswCCMVXLqe1KLSzESTU4u1T0egs9fy224
gahFzuZ8xQMQsk69OU0inVvGzaYJRKELVx9IrsrsI1pXeTc0Nfe1yFDNBrDtCQQF
WnbY6SGFzr0Pv4gsu9Xr
=1xnJ
-----END PGP SIGNATURE-----

--nextPart2311106.RTmiUEvLIW--