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,
On Monday 09 November 2015 14:41:50 Hubert Kario via RT wrote:
> Looks like rekeying is on the table again for TLSv1.3:
> https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
>
> so I'd say this issue should get fixed or at least workarounded
> (allowed in case the identity doesn't chan
On Monday 09 November 2015 17:00:45 Kaduk, Ben via RT wrote:
> On 11/09/2015 08:41 AM, Hubert Kario via RT wrote:
> > Looks like rekeying is on the table again for TLSv1.3:
> > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
>
> The proposed rekeying mechanism is not looking like r
On 11/09/2015 08:41 AM, Hubert Kario via RT wrote:
> Looks like rekeying is on the table again for TLSv1.3:
> https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
The proposed rekeying mechanism is not looking like renegotiation...
> so I'd say this issue should get fixed or at least w
Looks like rekeying is on the table again for TLSv1.3:
https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
so I'd say this issue should get fixed or at least workarounded (allowed
in case the identity doesn't change)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Securit
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 exploits would not work, because the
>>
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 exploits would not work, because the
>>
On 02/11/15 10:16, Albe Laurenz via RT wrote:
> 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
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
On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote:
> On 25/10/15 11:12, Albe Laurenz via RT wrote:
> > 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
> legitim
On 25/10/15 11:12, Albe Laurenz via RT wrote:
> 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 init
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. As it is during the initial handshake th
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. As it is during the initial handshake th
On 23/10/15 15:33, Albe Laurenz wrote:
> 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/Cl
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 e
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 e
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 ever
>
> (Albe, please
On Monday 19 October 2015 10:19:09 Albe Laurenz via RT wrote:
> 7 0.18990200010.155.6.40 10.153.93.229 TLSv1259
> Client Hello
> 8 0.19269900010.153.93.229 10.155.6.40 TLSv11485
> Server Hello, Certificate, Server Key Exchange, Server Hel
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 reali
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 reali
On Friday 16 October 2015 13:52:14 Matt Caswell via RT wrote:
> On 16/10/15 10:56, Hubert Kario via RT wrote:
> > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
> >> So now I really don't know what the "right" way forward is. Should
> >> we
> >> be applying the patch or not?
> >
> >
On 16/10/15 10:56, Hubert Kario via RT wrote:
> On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
>> So now I really don't know what the "right" way forward is. Should we
>> be applying the patch or not?
>
> I can't think of a way to exploit it if two assumptions hold:
> 1). we have
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:
>> https://www.ietf.org/mail-archive/web/tls/current/threads.html
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:
>> https://www.ietf.org/mail-archive/web/tls/current/threads.html
On 16/10/15 11:57, Kurt Roeckx via RT wrote:
> On Fri, Oct 16, 2015 at 08:53:06AM +, Matt Caswell via RT wrote:
>>
>> So now I really don't know what the "right" way forward is. Should we be
>> applying the patch or not?
>
> Has anybody contact Oracle about this issue? It seems useful that
On Fri, Oct 16, 2015 at 08:53:06AM +, Matt Caswell via RT wrote:
>
> So now I really don't know what the "right" way forward is. Should we be
> applying the patch or not?
Has anybody contact Oracle about this issue? It seems useful that
they fix it on their end, regardless of what we do.
K
On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
> On 13/10/15 12:31, Hubert Kario via RT wrote:
> > On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
> >> On 12/10/15 17:19, Matt Caswell via RT wrote:
> >>> On 12/10/15 16:39, Matt Caswell via RT wrote:
> The value of
On Friday 16 October 2015 09:55:41 Matt Caswell wrote:
> On 16/10/15 09:53, Matt Caswell via RT wrote:
> > On 13/10/15 12:31, Hubert Kario via RT wrote:
> >> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
> >>> On 12/10/15 17:19, Matt Caswell via RT wrote:
> On 12/10/15 16:39,
On 16/10/15 09:53, Matt Caswell via RT wrote:
>
>
> On 13/10/15 12:31, Hubert Kario via RT wrote:
>> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
>>> On 12/10/15 17:19, Matt Caswell via RT wrote:
On 12/10/15 16:39, Matt Caswell via RT wrote:
> The value of "in_read_ap
On 13/10/15 12:31, Hubert Kario via RT wrote:
> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
>> On 12/10/15 17:19, Matt Caswell via RT wrote:
>>> On 12/10/15 16:39, Matt Caswell via RT wrote:
The value of "in_read_app_data" not being true when it is supposed
to
ap
On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
> On 12/10/15 17:19, Matt Caswell via RT wrote:
> > On 12/10/15 16:39, Matt Caswell via RT wrote:
> >> The value of "in_read_app_data" not being true when it is supposed
> >> to
> >> appears to be running into a slightly different bug.
On 13/10/15 11:55, Hubert Kario via RT wrote:
>>> The value of "in_read_app_data" not being true when it is supposed
>>> to
>>> appears to be running into a slightly different bug. It's also
>>> present in 1.0.2 but you have to switch off version negotiation. So
>>> running s_server like this in
On Monday 12 October 2015 16:19:43 Matt Caswell via RT wrote:
> On 12/10/15 16:39, Matt Caswell via RT wrote:
> > On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
> >> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT
wrote:
> >>> On Friday 09 October 2015 18:05:19 Matt Caswell via
On 12/10/15 17:19, Matt Caswell via RT wrote:
>
>
> On 12/10/15 16:39, Matt Caswell via RT wrote:
>>
>>
>> On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
>>> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
On Friday 09 October 2015 18:05:19 Matt Caswell via RT wro
On 12/10/15 20:40, Kurt Roeckx via RT wrote:
> On Mon, Oct 12, 2015 at 06:54:46PM +, Matt Caswell via RT wrote:
>>
>>
>> On 12/10/15 19:11, Kurt Roeckx via RT wrote:
>>> On Mon, Oct 12, 2015 at 04:19:43PM +, Matt Caswell via RT wrote:
Having done some more digging it seems the p
On Mon, Oct 12, 2015 at 06:54:46PM +, Matt Caswell via RT wrote:
>
>
> On 12/10/15 19:11, Kurt Roeckx via RT wrote:
> > On Mon, Oct 12, 2015 at 04:19:43PM +, Matt Caswell via RT wrote:
> >>
> >> Having done some more digging it seems the problem only occurs if you
> >> get the initial han
On 12/10/15 19:11, Kurt Roeckx via RT wrote:
> On Mon, Oct 12, 2015 at 04:19:43PM +, Matt Caswell via RT wrote:
>>
>> Having done some more digging it seems the problem only occurs if you
>> get the initial handshake, following by a second reneg handshake *and*
>> interleaved app data all wit
On Mon, Oct 12, 2015 at 04:19:43PM +, Matt Caswell via RT wrote:
>
> Having done some more digging it seems the problem only occurs if you
> get the initial handshake, following by a second reneg handshake *and*
> interleaved app data all within the scope of a *single* SSL_read call.
> AFAICT
> AFAICT if SSL_read returns between the first handshake and the second, you
> don't get the problem.
I think it should not matter when or what SSL_read returns. That should only
be returning application-level data to the caller. All state manipulations,
etc., should be done underneath and com
> AFAICT if SSL_read returns between the first handshake and the second, you
> don't get the problem.
I think it should not matter when or what SSL_read returns. That should only
be returning application-level data to the caller. All state manipulations,
etc., should be done underneath and com
On 12/10/15 16:39, Matt Caswell via RT wrote:
>
>
> On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
>> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
>>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
On 09/10/15 19:02, Hubert Kario via RT wrote:
>>
On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
>>> On 09/10/15 19:02, Hubert Kario via RT wrote:
And for good measure, I also created a test script tha
On Mon, 2015-09-28 at 11:35 +, Albe Laurenz via RT wrote:
> The RFC writes:
>
>Note: If a rehandshake occurs while data is flowing on a
> connection,
>the communicating parties may continue to send data using the old
>CipherSpec. However, once the ChangeCipherSpec has been sent,
On Mon, 2015-09-28 at 11:35 +, Albe Laurenz via RT wrote:
> The RFC writes:
>
>Note: If a rehandshake occurs while data is flowing on a
> connection,
>the communicating parties may continue to send data using the old
>CipherSpec. However, once the ChangeCipherSpec has been sent,
On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
> > On 09/10/15 19:02, Hubert Kario via RT wrote:
> > > And for good measure, I also created a test script that
> > > combines fragmentation with interleaving.
> >
>
On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
> On 09/10/15 19:02, Hubert Kario via RT wrote:
> > And for good measure, I also created a test script that
> > combines fragmentation with interleaving.
>
> Did you try my patch with it? And if so what happened?
I'm using interleave-d
On Fri, Oct 09, 2015 at 06:05:19pm +, Matt Caswell via RT wrote:
>
>
> On 09/10/15 19:02, Hubert Kario via RT wrote:
> > And for good measure, I also created a test script that
> > combines fragmentation with interleaving.
>
> Did you try my patch with it? And if so what happened?
I just tr
On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
> On 09/10/15 19:02, Hubert Kario via RT wrote:
> > And for good measure, I also created a test script that
> > combines fragmentation with interleaving.
>
> Did you try my patch with it? And if so what happened?
no, I didn't (sorry, i
On 09/10/15 19:02, Hubert Kario via RT wrote:
> And for good measure, I also created a test script that
> combines fragmentation with interleaving.
Did you try my patch with it? And if so what happened?
Thanks
Matt
___
openssl-dev mailing list
To u
And for good measure, I also created a test script that
combines fragmentation with interleaving.
In other words, checks if writing first part of Handshake
protocol message, Application Data and then rest of
Handshake protocol message is handled correctly.
The script is in the same repository, na
A simpler interpretation would be that application data should never be sent or
received with sequence number = 0; only finished messages may have this
sequence number.
For connections with NPN enabled, we may need a slightly more complex rule.
In TLS we can also assume that encrypted fragments w
A simpler interpretation would be that application data should never be sent or
received with sequence number = 0; only finished messages may have this
sequence number.
For connections with NPN enabled, we may need a slightly more complex rule.
In TLS we can also assume that encrypted fragments w
On Wednesday 30 September 2015 09:37:37 Albe Laurenz wrote:
> 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
> >>> rec
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. By the wording in the RFC it would be va
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. By the wording in the RFC it would be va
On 28/09/15 12:35, Albe Laurenz via RT wrote:
> 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.
>
>> H
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 s
On Friday 25 September 2015 14:20:40 Hubert Kario wrote:
> On Friday 25 September 2015 11:40:27 Matt Caswell wrote:
> > On 25/09/15 11:25, Hubert Kario via RT wrote:
> > > On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
> > >> However, I have some concerns with the wording of the RFC. It
>
On Friday 25 September 2015 12:42:14 Karthikeyan Bhargavan wrote:
> During renegotiation, app data should not appear between CCS and
> finished, but some implementations (e.g. NSS) do allow this. I would
> consider it a state machine bug, although finding a serious exploit
> is not so easy.
while
On Friday 25 September 2015 11:40:27 Matt Caswell wrote:
> On 25/09/15 11:25, Hubert Kario via RT wrote:
> > On Friday 25 September 2015 10:47:42 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 re
During renegotiation, app data should not appear between CCS and finished, but
some implementations (e.g. NSS) do allow this.
I would consider it a state machine bug, although finding a serious exploit is
not so easy.
> On 25 Sep 2015, at 12:40, Matt Caswell wrote:
>
>
>
> On 25/09/15 11:25,
On 25/09/15 11:25, Hubert Kario via RT wrote:
> On Friday 25 September 2015 10:47:42 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. By the wording in the RFC i
On 25/09/15 11:25, Hubert Kario via RT wrote:
>
> A Finished message is always sent immediately after a change
> cipher spec message to verify that the key exchange and
> authentication processes were successful.
This is perhaps the key statement. It could do with being more e
On Friday 25 September 2015 10:47:42 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. By the wording in the RFC it would be valid for app
> data to be received *after
On 24/09/15 21:40, Hubert Kario via RT wrote:
> I have made the reproducer cleaner and it should use relatively stable
> API's of tlsfuzzer now.
>
> openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\
> -nodes -batch
> ~/dev/openssl/apps/openssl s_server -key localhost.key -
On 24/09/15 21:40, Hubert Kario via RT wrote:
> I have made the reproducer cleaner and it should use relatively stable
> API's of tlsfuzzer now.
>
> openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\
> -nodes -batch
> ~/dev/openssl/apps/openssl s_server -key localhost.key -
I have made the reproducer cleaner and it should use relatively stable
API's of tlsfuzzer now.
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\
-nodes -batch
~/dev/openssl/apps/openssl s_server -key localhost.key -cert\
localhost.crt
pip install --pre tlslite-ng
git clone
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 u
On Thursday 19 February 2015 13:48:43 Hubert Kario wrote:
> On Wednesday 18 February 2015 23:49:39 Stephen Henson via RT wrote:
> > On Wed Feb 18 21:12:09 2015, laurenz.a...@wien.gv.at wrote:
> > > I ran into this problem while connecting to a PostgreSQL server
> > > (PostgreSQL uses OpenSSL
> > >
On Wednesday 18 February 2015 23:49:39 Stephen Henson via RT wrote:
> On Wed Feb 18 21:12:09 2015, laurenz.a...@wien.gv.at wrote:
> > 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 dr
On Wed Feb 18 21:12:09 2015, laurenz.a...@wien.gv.at wrote:
> 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'
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 potential
73 matches
Mail list logo