Hubert Kario wrote:
> The bug is still present in version tagged as OpenSSL_1_1_0-pre1
>
> Moreover I've verified that the miTLS implementation[1] shows expected
> behaviour - it accepts the interleaved application data everywhere but
> between CCS and Finished.
I don't know if that is feasible,
Matt Caswell wrote:
> On 02/11/15 10:16, Albe Laurenz via RT wrote:
>> If interleaved application data are only allowed
>> a) before Change Cipher Spec
>> b) during a renegotiation, i.e., when the connection is encrypted
>>
>> your second example and similar
Hubert Kario wrote:
> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote:
>> My concern though is broader than this specific case. I have given two
>> *examples* of exploits that we may open ourselves up to if we attempt
>> to process this application data without some fairly significant
Hubert Kario wrote:
> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote:
>> My concern though is broader than this specific case. I have given two
>> *examples* of exploits that we may open ourselves up to if we attempt
>> to process this application data without some fairly significant
Matt Caswell wrote:
> On 23/10/15 15:33, Albe Laurenz wrote:
>> Matt Caswell wrote:
>>> Imagine an attacker who is able to eavesdrop on messages between a
>>> legitimate client who presents a client certificate to the server during
>>> the initial handshake. A
Matt Caswell wrote:
> On 23/10/15 15:33, Albe Laurenz wrote:
>> Matt Caswell wrote:
>>> Imagine an attacker who is able to eavesdrop on messages between a
>>> legitimate client who presents a client certificate to the server during
>>> the initial handshake. A
Matt Caswell wrote:
> On 16/10/15 16:05, Hubert Kario via RT wrote:
>> we may actually be able to patch this up partially in 1.0.x
>>
>> the original problem description mentions server being unable to process
>> application data before Certificate/Client Key Exchange, not in any
>> place what so
Hubert Kario wrote:
>> Fixing this sort of problem is going to be *hard* and probably require
>> quite a lot of non-trivial changes - definitely not the sort of the
>> thing I want to be doing in a stable branch. Fixing this is an
>> example of what I meant by "onerous mitigations", but I now
Hubert Kario wrote:
>> Fixing this sort of problem is going to be *hard* and probably require
>> quite a lot of non-trivial changes - definitely not the sort of the
>> thing I want to be doing in a stable branch. Fixing this is an
>> example of what I meant by "onerous mitigations", but I now
Hubert Kario wrote:
> On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
>> I raised the ambiguity in the spec about when in the handshake
>> interleaved app data is allowed with the TLS WG. You can see the
>> thread here:
>>
Matt Caswell wrote:
> On 28/09/15 12:35, Albe Laurenz via RT wrote:
>> Matt Caswell wrote:
>>> However, I have some concerns with the wording of the RFC. It seems to
>>> place no limits whatsoever on when it is valid to receive app data in
>>> the handshake
Matt Caswell wrote:
> On 28/09/15 12:35, Albe Laurenz via RT wrote:
>> Matt Caswell wrote:
>>> However, I have some concerns with the wording of the RFC. It seems to
>>> place no limits whatsoever on when it is valid to receive app data in
>>> the handshake
Matt Caswell wrote:
> I've been looking into this issue. The reason this fails is because at
> some point in the past there has been an explicit design decision to
> disallow it.
Thank you for your work!
I agree with your analysis.
> However, I have some concerns with the wording of the RFC. It
Thanks for looking into this, and thanks for providing a reproducer.
I just tried with the current git HEAD from 2015-02-23 (1.1.0) and was
able to reproduce the bug with PostgreSQL.
I just saw that there is bug #2481 which is probably the same problem.
This bug was created in 2011 and is still
I ran into this problem while connecting to a PostgreSQL server (PostgreSQL
uses OpenSSL
for SSL support) with a Java client using the PostgreSQL JDBC driver (which uses
the Java Secure Socket Extension which is part of Oracle's Java Runtime
Environment).
Since database connections are
15 matches
Mail list logo
