On Fri, Sep 25, 2015 at 02:02:36pm +, Hubert Kario via RT wrote:
> On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote:
> > On Fri, Sep 25, 2015 at 01:20:12pm +, Hubert Kario via RT wrote:
> > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > > branches
On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 02:02:36pm +, Hubert Kario via RT wrote:
> > On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT
wrote:
> > > On Fri, Sep 25, 2015 at 01:20:12pm +, Hubert Kario via RT
wrote:
> > >
On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote:
> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> > As a matter of test I changed the ssl_get_message() in
> > ssl3_get_client_hello() to use 0xFF (uint24 max) as maximum size,
>
> it doesn't have in
>> > and recognize two new settings,
>> > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this.
>>
>> While NO_NEON might make sense, I really see no reason to introduce
>> THUMB_ONLY. Because pre-defines set by the compiler driver are
>> sufficient.
>>
>>
>>
On Friday 25 September 2015 16:33:40 Matt Caswell wrote:
> On 25/09/15 14:19, Hubert Kario wrote:
> > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > branches reject Client Hello messages bigger than 2^14+4 bytes.
>
> Right. The reason for that is that there is an explicit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/09/15 14:19, Hubert Kario wrote:
> Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> branches reject Client Hello messages bigger than 2^14+4 bytes.
Right. The reason for that is that there is an explicit (deliberate)
check
On Friday 25 September 2015 16:33:40 Matt Caswell wrote:
> On 25/09/15 14:19, Hubert Kario wrote:
> > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > branches reject Client Hello messages bigger than 2^14+4 bytes.
>
> Right. The reason for that is that there is an explicit
Gahhhdidn't mean to open this as a new ticket.
Closing.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
>>> As a matter of test I changed the ssl_get_message() in
>>> ssl3_get_client_hello() to use
On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
>>> As a matter of test I changed the ssl_get_message() in
>>> ssl3_get_client_hello() to use
sorry, duplicate of #4063, please close
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: PGP signature
___
On Fri, Sep 25, 2015 at 09:19:02PM +0200, Kurt Roeckx wrote:
> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's
> > On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > > FWIW I checked a couple of TLS implementations I have around (GnuTLS
> > > and s2n), and AFAICT they don't check for a maximum size at all.
> >
> > what do you mean by that? As we've said with Matt, you can't create a
On Fri, Sep 25, 2015 at 04:23:27PM +, Hubert Kario via RT wrote:
>
> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends
> up as an extension, possibly multiple ones), and that quantum computing
> resistant algorithms usually require fairly large key sizes (large
>
On Fri, Sep 25, 2015 at 04:23:27PM +, Hubert Kario via RT wrote:
>
> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends
> up as an extension, possibly multiple ones), and that quantum computing
> resistant algorithms usually require fairly large key sizes (large
>
On Thu Sep 24 11:52:05 2015, steve wrote:
>
> I've tried a newer version of VC++ and I also get the "No Applink"
> error when
> it is trying to embed the fingerprint in libeay32.dll. I'll see if
> this can be
> fixed.
Please try the attached patch.
Steve.
--
Dr Stephen N. Henson. OpenSSL project
On Fri, Sep 25, 2015 at 04:17:33PM +, Matt Caswell via RT wrote:
>
>
> On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote:
> >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> >>> As a matter of
(since we're not talking about OpenSSL any more, I'm dropping the RT)
On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> FWIW I checked a couple of TLS implementations I have around (GnuTLS
> and s2n), and AFAICT they don't check for a maximum size at all.
what do you mean
On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 04:17:33PM +, Matt Caswell via RT wrote:
> > On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > > On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT
wrote:
> > >> On Friday 25
On Fri, Sep 25, 2015 at 05:11:39pm +, Hubert Kario via RT wrote:
> On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > On Fri, Sep 25, 2015 at 04:17:33PM +, Matt Caswell via RT wrote:
> > > On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > > > On Fri, Sep 25,
On Fri, Sep 25, 2015 at 07:06:31PM +0200, Hubert Kario wrote:
> (since we're not talking about OpenSSL any more, I'm dropping the RT)
>
> On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > FWIW I checked a couple of TLS implementations I have around (GnuTLS
> > and s2n),
On 25/09/15 20:19, Kurt Roeckx wrote:
> On Fri, Sep 25, 2015 at 04:23:27PM +, Hubert Kario via RT wrote:
>>
>> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends
>> up as an extension, possibly multiple ones), and that quantum computing
>> resistant algorithms usually
> On the other side of the coin handling very large ClientHello's is not without
> cost and risk.
As long as it's a #define that can be changed in ssl.h (or a runtime global?
Ick) we should be okay.
___
openssl-dev mailing list
To unsubscribe:
On Sat, Sep 26, 2015 at 12:17:20AM +, Salz, Rich wrote:
> > On the other side of the coin handling very large ClientHello's is not
> > without
> > cost and risk.
>
> As long as it's a #define that can be changed in ssl.h (or a runtime global?
> Ick) we should be okay.
It would have to
Bonjour,
> Le 24 sept. 2015 à 21:59, Justin Burke a écrit
> :
>
> Hello,
>
> Does OpenSSL support TLS with SHA2-512? I'm able to compile 1.0.1p with
> SHA2-256 and SHA2-384 support, but not with SHA2-512. `openssl ciphers`
> does not list any SHA512 cipher, while
On 09/21/2015 12:01 AM, Jan Ehrhardt wrote:
> Dr. Matthias St. Pierre in gmane.comp.encryption.openssl.devel (Sun, 16
> Aug 2015 23:52:21 +0200):
>>
>> Thank you once more for the detailed reply. I applied your patches
>> provisorily before going on vacation last friday to keep the builds
>>
Hi,
> Does OpenSSL support TLS with SHA2-512?
No, since there is no such thing as a TLS cipher suite with SHA512.
Cipher suites need to be registered and assigned IDs, so servers/clients
can exchange those IDs to announce what cipher suites they support.
And if you look at the probably
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
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 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
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
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:
>
>
>
>
Hello,
due to commit a93d3e0 the ./config script currently fails with the error:
> Operating system: x86_64-whatever-linux2
> This system (linux-x86_64) is not supported. See file INSTALL for details.
see the following GitHub pull request for a fix:
https://github.com/openssl/openssl/pull/412
Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite branches
reject Client Hello messages bigger than 2^14+4 bytes.
RFC 5246 specifies maximum size of just the extensions field to be
2^16-1:
struct {
ProtocolVersion client_version;
Random random;
On Fri, Sep 25, 2015 at 01:20:12pm +, Hubert Kario via RT wrote:
> Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite branches
> reject Client Hello messages bigger than 2^14+4 bytes.
IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think the problem is
that OpenSSL only
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
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
On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 01:20:12pm +, Hubert Kario via RT wrote:
> > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > branches reject Client Hello messages bigger than 2^14+4 bytes.
>
> IIRC SSLv3 does
Patch applied. Thanks.
Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Closing this ticket. Please use the API suggested by Steve.
Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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
42 matches
Mail list logo