I don't have access unfortunately, but I wonder which companies on this mailing
list are using the affected APC devices.
From: Peter Gutmann
Sent: Sunday, July 24, 2016 5:01:42 AM
To: Yuhong Bao
Subject: RE: [TLS] Thoughts on Version Intolerance
Do you
- Original Message -
> From: "David Benjamin"
> To: "Brian Smith" , "Hubert Kario"
> Cc: ""
> Sent: Saturday, July 23, 2016 8:03:41 AM
> Subject: Re: [TLS] Thoughts on Version Intolerance
> On Sat, Jul 23, 2016 at 3:37 AM Bri
- Original Message -
> From: "Brian Smith"
> To: "Hubert Kario"
> Cc: "Dave Garrett" , ""
> Sent: Saturday, July 23, 2016 3:37:24 AM
> Subject: Re: [TLS] Thoughts on Version Intolerance
>
> Hubert Kario wrote:
> >
On 20/07/2016 12:01, Hanno Böck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by
>> using extension based mechanism to indicate TLSv1.3,
>
> Just quick: This was discussed yesterday, David Benjamin had an
>
On Sat, Jul 23, 2016 at 3:37 AM Brian Smith wrote:
> Hubert Kario wrote:
> > I'm quite sure that if I were sending a huge extension or many big
> extensions,
> > the percentage of servers that are incompatible to them would be
> similar, if
> > not worse. A relatively small 3KiB client hello alr
Hubert Kario wrote:
> I'm quite sure that if I were sending a huge extension or many big extensions,
> the percentage of servers that are incompatible to them would be similar, if
> not worse. A relatively small 3KiB client hello already causes issues and this
> is not exactly something impossible
On Thursday, 21 July 2016 16:04:25 CEST Dave Garrett wrote:
> On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote:
> > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> > > Any ClientHello with > 200 Cipher suite code points indicates fairly
> > > insane
> > > Client behaviour, so
On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote:
> On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> > Any ClientHello with > 200 Cipher suite code points indicates fairly insane
> > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.
>
> and which part of
On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote:
> Martin Rex writes:
> >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
> >X.509v3 certificates can theoretically include CAT MPEGs and amount to
> >megabytes.
>
> We really need a TLS scanner that does this ju
Martin Rex writes:
>Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
>X.509v3 certificates can theoretically include CAT MPEGs and amount to
>megabytes.
We really need a TLS scanner that does this just to see what happens. When I
created that cat-MPEG cert, I fed it to
On Thu, Jul 21, 2016 at 10:19:34AM +, David Benjamin wrote:
> On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote:
>
> > On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > > On Wed, 20 Jul 2016 11:20:46 +0200
> > > Hubert Kario wrote:
> > >
> And as Hubert notes, there may well be other intoler
On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > Martin Rex wrote:
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target&victim of the POO
On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote:
> On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > On Wed, 20 Jul 2016 11:20:46 +0200
> > Hubert Kario wrote:
> >
> >> so it looks to me like while we may gain a bit of compatibility by
> >> using extension based mechanism to indicate TLSv1.3,
>
On Jul 20, 2016 10:31 AM, "Martin Rex" wrote:
>
> Hubert Kario wrote:
> > Martin Rex wrote:
> >>
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target&victim of the POODLE a
Hubert Kario wrote:
> Martin Rex wrote:
>>
>> Forget TLS extensions, forget ClientHello.client_version.
>> Both in fundamentally broken, and led to Web Browsers coming up
>> with the "downgrade dance" that is target&victim of the POODLE attack.
>>
>> We know fairly reliably what kind of negotiatio
On 07/20/2016 05:01 AM, Hanno Böck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> i
On Wednesday, 20 July 2016 06:24:50 CEST Watson Ladd wrote:
> On Wed, Jul 20, 2016 at 6:13 AM, Hubert Kario wrote:
> > On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
>
>
> > I think that implementing complex binary cryptographic protocols is simply
> > hard.
>
> And what conclusion s
On Wed, Jul 20, 2016 at 6:13 AM, Hubert Kario wrote:
> On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
> I think that implementing complex binary cryptographic protocols is simply
> hard.
>
And what conclusion should one draw about TLS 2.0 (*ahem* 1.3) as a
result of this realization?
On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
> > it's not IETF's fault that the implementers add unspecified by IETF
> > restrictions and limitations to parsers of Client Hello messages or that
> > they can't handle handshake messages split over multiple record layer
> > messages, desp
> it's not IETF's fault that the implementers add unspecified by IETF
> restrictions and limitations to parsers of Client Hello messages or that
> they can't handle handshake messages split over multiple record layer
> messages, despite the standard being very explicit in that they MUST
> support t
On Wednesday, 20 July 2016 13:57:36 CEST Ilari Liusvaara wrote:
> On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote:
> > So I have partial results after scanning around 14 000 domains.
> > The scanner was able to connect to 12 606 hosts that presented unexpired
> > certificates signed by
On Wednesday, 20 July 2016 12:14:01 CEST Martin Rex wrote:
> Hanno Böck wrote:
>
> Checking application/pgp-signature: FAILURE
>
> > Hubert Kario wrote:
> >> so it looks to me like while we may gain a bit of compatibility by
> >> using extension based mechanism to indicate TLSv1.3,
>
> Forget T
On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote:
>
> So I have partial results after scanning around 14 000 domains.
> The scanner was able to connect to 12 606 hosts that presented unexpired
> certificates signed by CA's in Mozilla root program.
>
> Of those:
> 93% support TLSv1.2 p
Hanno Böck wrote:
Checking application/pgp-signature: FAILURE
> Hubert Kario wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by
>> using extension based mechanism to indicate TLSv1.3,
Forget TLS extensions, forget ClientHello.client_version.
Both in fundamentally bro
On Wed, 20 Jul 2016 11:20:46 +0200
Hubert Kario wrote:
> so it looks to me like while we may gain a bit of compatibility by
> using extension based mechanism to indicate TLSv1.3,
Just quick: This was discussed yesterday, David Benjamin had an
interesting proposal, but it was largely met with res
On Monday, 18 July 2016 15:08:03 CEST Hubert Kario wrote:
> On Monday 18 July 2016 13:08:43 Hanno Böck wrote:
> > * We don't have good data on the issue. The latest numbers I could find
> >
> > came from Ivan Ristic in 2013 [4], and from David Benjamin we know he
> > considers the problem to b
If we keep trying to salvage the ClientHello version number, we will be
chasing down intolerance forever. (And I'm honestly bored of doing that.)
I'd prefer we move it to an extension. Either an empty indicator extension
for each version or a single version extension with a list of versions. Or
may
On Mon, Jul 18, 2016 at 01:08:43PM +0200, Hanno Böck wrote:
> Hi,
>
> Recently both Adam Langley [1] and David Benjamin [2] indicated that
> they expect with TLS 1.3 Browsers will have to bring back the infamous
> version falbacks that caused so much trouble in the past (POODLE etc.)
> to work aro
On Monday 18 July 2016 13:08:43 Hanno Böck 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
Hi,
Recently both Adam Langley [1] and David Benjamin [2] indicated that
they expect with TLS 1.3 Browsers will have to bring back the infamous
version falbacks that caused so much trouble in the past (POODLE etc.)
to work around broken implementations of the TLS handshake.
I don't blame browser
30 matches
Mail list logo
