Ilari Liusvaara writes:
>On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
>> It also means you're going to be in for a rude shock when you encounter the
>> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.
>
>That did not check for interop with any mainstre
Yoav Nir writes:
>But if at some point all websites use HTTP-whatever-the-current-version-is
>then maybe browsers can remove support for HTTP/1.1 and then your
>embedded/SCADA/IoT devices won’t give us that rude shock.
Since HTTP/2 pretty much guarantees that SCADA/IoT/etc will keep using HTTP
1
On Wednesday, 21 September 2016 15:53:33 CEST Peter Gutmann wrote:
> Andreas Walz writes:
> >Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
> >addresses this in the Presentation Language section:
> >
> > "Peers which receive a message which cannot be parsed according t
On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
> Martin Thomson writes:
>
> >The advantage with deploying a new protocol is that you can be strict. If,
> >for example, all of the browsers implement TLS 1.3 and are strict, then
> >Amazon won't be able to deploy a buggy 1.3 implem
> On 22 Sep 2016, at 8:11 AM, Peter Gutmann wrote:
>
> Martin Thomson writes:
>
>> The advantage with deploying a new protocol is that you can be strict. If,
>> for example, all of the browsers implement TLS 1.3 and are strict, then
>> Amazon won't be able to deploy a buggy 1.3 implementatio
Martin Thomson writes:
>The advantage with deploying a new protocol is that you can be strict. If,
>for example, all of the browsers implement TLS 1.3 and are strict, then
>Amazon won't be able to deploy a buggy 1.3 implementation without noticing
>pretty quickly. You might suggest that that'
You describe the observation that leads to Postel's maxim, namely that
if you found the internet in a mess when you got there, then you have
to be tolerant of rubbish.
The advantage with deploying a new protocol is that you can be strict.
If, for example, all of the browsers implement TLS 1.3 and
On Wed, Sep 21, 2016 at 03:53:33PM +, Peter Gutmann wrote:
> Andreas Walz writes:
>
> Error: Couldn't connect to Amazon because decoding_error alert>.
>
> What would you put for the explanation for this case? And if you say "decode
> error" the user's response will be to switch
Andreas Walz writes:
>Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
>addresses this in the Presentation Language section:
>
> "Peers which receive a message which cannot be parsed according to the
> syntax (e.g., have a length extending beyond the message boundary o
On Wednesday, 21 September 2016 11:45:15 CEST Andreas Walz wrote:
> Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
> fact that the TLS 1.3 draft now explicitly addresses this in the
> Presentation Language section:
>
> "Peers which receive a message which cannot
Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
fact that
the TLS 1.3 draft now explicitly addresses this in the Presentation Language
section:
"Peers which receive a message which cannot be parsed according to the
syntax
(e.g., have a length extending b
On 21 September 2016 at 17:21, Andreas Walz
wrote:
> Do you see any argument why ignoring such trailing data would be acceptable
> (or even desirable)?
No.
Well, we exploited that to add extensions to the protocol once, so I
won't categorically rule it out, but in the case of
supported_groups/su
Dear all,
sorry for bringing up this thread again. We were doing some further studies
with TLS implementations (all TLS 1.2) for embedded systems and found more
cases where, within substructures of handshake messages, trailing data without
any associated field in the specification is *not* reje
On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> Hi,
>
> >>> Hubert Kario 09/12/16 6:56 PM >>>
> >
> > are you aware of the tlsfuzzer framework?
> > https://github.com/tomato42/tlsfuzzer
>
> @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
> repository
Hi,
>>> Hubert Kario 09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer
@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
repository before and I skimmed through the code. However, I didn't run the
code and I don't kno
Martin Rex writes:
>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently maki
On Friday, 9 September 2016 16:23:52 CEST Andreas Walz wrote:
> Dear all,
>
> we are working on an approach/framework for testing TLS implementations
> (currently only servers, but clients are planned for the future as well).
are you aware of the tlsfuzzer framework?
https://github.com/tomato42/t
I think that Martin (R) provided you with the answers I would have.
Have you filed bugs against the servers in question for the issues
that you have seen?
On 10 September 2016 at 00:23, Andreas Walz
wrote:
> Dear all,
>
> we are working on an approach/framework for testing TLS implementations
>
My personal take on your questions:
Andreas Walz wrote:
>
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression
> even if that has not been in the ClientHello's list.
Sounds like reasonable behaviour (i
Dear all,
we are working on an approach/framework for testing TLS implementations
(currently only servers, but clients are planned for the future as well). While
running our tests against a bunch of different TLS (server) implementations, we
found several types of suspicious behaviour (see belo
20 matches
Mail list logo
