Re: [openssl-dev] TLS 1.3 client hello issue
Thanks for responding. Yes, I have done the steps mentioned above. Here
are my settings:
int min_version = TLS1_3_VERSION, max_version = TLS1_3_VERSION;
meth = isClient ? tlsv1_3_client_method() : tlsv1_3_server_method();
//meth = isClient ? TLS_client_method() : TLS_server_method();
///
// Create new SSL context using the chosen SSL_METHOD
ctx = SSL_CTX_new(meth);
if (ctx == NULL)
{
// throw error
}
if (SSL_CTX_set_min_proto_version(ctx, min_version) == 0)
{
// throw error
}
if (SSL_CTX_set_max_proto_version(ctx, max_version) == 0)
{
// throw error
}
// Configure SSL to use the cipher suite specified
// TLS1_3_TXT_AES_128_GCM_SHA256
// ./include/openssl/tls1.h:# define
TLS1_3_TXT_AES_128_GCM_SHA256 "TLS13-AES-128-GCM-SHA256"
int set_cipher;
if (! (set_cipher = SSL_CTX_set_cipher_list(ctx, cipherSuite.c_str())) )
{
throw (InvalidTestConfiguration("OpenSslApi::OpenSslInitContext",
"Failed to set ciphers"));
}
The set_min_proto/set_max_proto calls succeed.
If I want to get the AES_128_GCM_SHA256 Cipher for TLS 1.3 to be used, are
these the steps to be used?
Should I instead, select also, AES128-GCM-SHA256 a TLS 1.2 cipher in the
list, and set the min_proto to TLS 1.2, and max_proto to 1.3 ? I need to
avoid hitting the default case below:
static WRITE_TRAN ossl_statem_client13_write_transition(SSL *s)
{
OSSL_STATEM *st = >statem;
/*
* Note: There are no cases for TLS_ST_BEFORE because we haven't
negotiated
* TLSv1.3 yet at that point. They are handled by
* ossl_statem_client_write_transition().
*/
switch (st->hand_state) {
default:
"
On Mon, Sep 18, 2017 at 5:40 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 09/18/2017 01:07 AM, Mahesh Bhoothapuri wrote:
>
> Hi,
>
> I am sending a Tls 1.3 client hello, and am seeing an issue with
>
> ossl_statem_client_write_transition in statem_clnt.c.
>
>
> /*
> * Note that immediately before/after a ClientHello we don't know what
> * version we are going to negotiate yet, so we don't take this branch
> until
> * later
> */
>
> /*
> * ossl_statem_client_write_transition() works out what handshake state to
> * move to next when the client is writing messages to be sent to the
> server.
> */
> WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
> {
>
> if (SSL_IS_TLS13(s))
> return ossl_statem_client13_write_transition(s);
> }
>
> And in:
>
>
> /*
> * ossl_statem_client_write_transition() works out what handshake state to
> * move to next when the client is writing messages to be sent to the
> server.
> */
> WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
> {
>
>/*
> * Note: There are no cases for TLS_ST_BEFORE because we haven't
> negotiated
> * TLSv1.3 yet at that point. They are handled by
> * ossl_statem_client_write_transition().
> */
>
> switch (st->hand_state) {
> default:
> /* Shouldn't happen */
> return WRITE_TRAN_ERROR;
>
> }
>
> With a TLS 1.3 client hello, using tls 1.3 version, the st->hand_state is
>
>
> Sorry, I just want to clarify what you are doing -- are you taking
> SSL_CTX_new(TLS_method()) and then calling SSL_CTX_set_min_proto_version(ctx,
> TLS1_3_VERSION) and SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION)?
>
> I note that there is no version-specific TLSv1_3_method() available, and
> in any case, it's of questionable wisdom to attempt to force TLS 1.3 only
> while the specification is still in draft status -- in any case where the
> client and server implementations are not tightly controlled, negotiation
> failures seem quite likely.
>
> TLS_ST_BEFORE and so, the default error is returned.
>
> When I added :
>
> case TLS_ST_BEFORE:
> st->hand_state = TLS_ST_CW_CLNT_HELLO;
> return WRITE_TRAN_CONTINUE;
>
>
> The reason there is not currently a case for TLS_ST_BEFORE is that whether
> or not we're going to be using TLS 1.3 is supposed to be determined on the
> server as part of version negotiation, so when we're sending a ClientHello,
> our version is in an indeterminate status -- the general-purpose TLS method
> must be used at that part of the handshake.
>
> The client hello gets sent out, but I only saw a TLS 1.2 version being
> sent.
> Is this a bug?
>
>
> The legacy_version field in a TLS 1.3 ClientHello will be 0x0303, matching
> the historical value for TLS 1.2. The actual list of versions are conveyed
> in a "supported_versions" extension, which is what you need to be looking
> at.
>
> -Ben
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] TLS 1.3 client hello issue
On 09/18/2017 01:07 AM, Mahesh Bhoothapuri wrote:
>
> Hi,
>
> I am sending a Tls 1.3 client hello, and am seeing an issue with
>
> ossl_statem_client_write_transition in statem_clnt.c.
>
>
> /*
> * Note that immediately before/after a ClientHello we don't know what
> * version we are going to negotiate yet, so we don't take this
> branch until
> * later
> */
>
> /*
> * ossl_statem_client_write_transition() works out what handshake state to
> * move to next when the client is writing messages to be sent to the
> server.
> */
> WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
> {
>
> if (SSL_IS_TLS13(s))
> return ossl_statem_client13_write_transition(s);
> }
>
> And in:
>
>
> /*
> * ossl_statem_client_write_transition() works out what handshake state to
> * move to next when the client is writing messages to be sent to the
> server.
> */
> WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
> {
>
> /*
> * Note: There are no cases for TLS_ST_BEFORE because we haven't
> negotiated
> * TLSv1.3 yet at that point. They are handled by
> * ossl_statem_client_write_transition().
> */
>
> switch (st->hand_state) {
> default:
> /* Shouldn't happen */
> return WRITE_TRAN_ERROR;
>
> }
>
> With a TLS 1.3 client hello, using tls 1.3 version, the st->hand_state is
Sorry, I just want to clarify what you are doing -- are you taking
SSL_CTX_new(TLS_method()) and then calling
SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION) and
SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION)?
I note that there is no version-specific TLSv1_3_method() available, and
in any case, it's of questionable wisdom to attempt to force TLS 1.3
only while the specification is still in draft status -- in any case
where the client and server implementations are not tightly controlled,
negotiation failures seem quite likely.
> TLS_ST_BEFORE and so, the default error is returned.
>
> When I added :
>
> case TLS_ST_BEFORE:
> st->hand_state = TLS_ST_CW_CLNT_HELLO;
> return WRITE_TRAN_CONTINUE;
>
The reason there is not currently a case for TLS_ST_BEFORE is that
whether or not we're going to be using TLS 1.3 is supposed to be
determined on the server as part of version negotiation, so when we're
sending a ClientHello, our version is in an indeterminate status -- the
general-purpose TLS method must be used at that part of the handshake.
> The client hello gets sent out, but I only saw a TLS 1.2 version being
> sent.
> Is this a bug?
The legacy_version field in a TLS 1.3 ClientHello will be 0x0303,
matching the historical value for TLS 1.2. The actual list of versions
are conveyed in a "supported_versions" extension, which is what you need
to be looking at.
-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] TLS 1.3 client hello issue
Hi,
I am sending a Tls 1.3 client hello, and am seeing an issue with
ossl_statem_client_write_transition in statem_clnt.c.
/*
* Note that immediately before/after a ClientHello we don't know what
* version we are going to negotiate yet, so we don't take this branch
until
* later
*/
/*
* ossl_statem_client_write_transition() works out what handshake state to
* move to next when the client is writing messages to be sent to the
server.
*/
WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
{
if (SSL_IS_TLS13(s))
return ossl_statem_client13_write_transition(s);
}
And in:
/*
* ossl_statem_client_write_transition() works out what handshake state to
* move to next when the client is writing messages to be sent to the
server.
*/
WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
{
/*
* Note: There are no cases for TLS_ST_BEFORE because we haven't
negotiated
* TLSv1.3 yet at that point. They are handled by
* ossl_statem_client_write_transition().
*/
switch (st->hand_state) {
default:
/* Shouldn't happen */
return WRITE_TRAN_ERROR;
}
With a TLS 1.3 client hello, using tls 1.3 version, the st->hand_state is
TLS_ST_BEFORE and so, the default error is returned.
When I added :
case TLS_ST_BEFORE:
st->hand_state = TLS_ST_CW_CLNT_HELLO;
return WRITE_TRAN_CONTINUE;
The client hello gets sent out, but I only saw a TLS 1.2 version being sent.
Is this a bug?
Thanks,
Mahesh
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
Whew, *finally* we got around to putting this into master. Thanks! :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4063 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
Alessandro's patch has now been applied (thanks). Closing this ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Fri, Oct 09, 2015 at 05:02:47pm +, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 07:57:21pm +, Alessandro Ghedini via RT wrote: > > FYI, I just pushed another patch that does the above (moving the check and > > sending an alert) which I think is the best option (although, as Hubert > > pointed > > out, sending the decode_error alert is not a MUST). If that's ok with you, I > > can squash the two commits together and give them a better message, > > otherwise > > just ignore the second patch. > > So, I went ahead and squashed all the commits into one [0] and also added the > SSLv2 check as well. Can someone please have a look? Ping? FYI I just rebased my patch at [0] on top of the state machine rewrite commits in master (in fact I've rebased all my patches on master). Cheers [0] https://github.com/openssl/openssl/pull/437 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 07:57:21pm +, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 06:26:27pm +, Alessandro Ghedini via RT wrote: > > On Thu, Oct 08, 2015 at 06:14:00pm +, Alessandro Ghedini via RT wrote: > > > On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote: > > > > On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote: > > > > > The server does not abort connection upon receiving a Client Hello > > > > > message with malformed session_id field. > > > > > > > > > > Affects 1.0.1, 1.0.2 and master. > > > > > > > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > > > > defined as > > > > > > > > > > opaque SessionID<0..32>; > > > > > > > > > > that means, that any SessionID longer than 32 bytes creates an > > > > > incorrectly formatted Client Hello message, and as such, should be > > > > > rejected. > > > > > > > > Looking at the code in master, for non-v2 ClientHello messages the code > > > > uses > > > > the PACKET_get_length_prefixed_1() function to extract the SessionID, > > > > however I > > > > see no way to pass a maximum allowed length to it. I think a new > > > > function would > > > > have to be added to the PACKET_* interface (I can look into this). > > > > Haven't > > > > checked older branches yet. > > > > > > So, it turns out the check was already performed, but this failure didn't > > > cause > > > the session to be aborted (the original PACKET was advanced anyway > > > though, even > > > is the session_id isn't actually extracted), I don't know if this was on > > > purpose though. > > > > Another thing to consider is that the client already aborts when an invalid > > session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER > > alert. > > > > My patch doesn't actually send any alert so the check should be moved > > earlier > > to allow an alert to be sent, if that is desired. > > FYI, I just pushed another patch that does the above (moving the check and > sending an alert) which I think is the best option (although, as Hubert > pointed > out, sending the decode_error alert is not a MUST). If that's ok with you, I > can squash the two commits together and give them a better message, otherwise > just ignore the second patch. So, I went ahead and squashed all the commits into one [0] and also added the SSLv2 check as well. Can someone please have a look? Anyway, I noticed that the client compares the session_id length against "sizeof s->session->session_id" (which is SSL_MAX_SSL_SESSION_ID_LENGTH, like I used in my patch), and also against SSL3_SESSION_ID_SIZE (which is equal to SSL_MAX_SSL_SESSION_ID_LENGTH). I think this second check is superfluous and the other one can just use SSL_MAX_SSL_SESSION_ID_LENGTH directly instead of sizeof (it'd be more obvious). Cheers [0] https://github.com/openssl/openssl/pull/437 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing
The GitHub pull request was merged, so this can be closed now. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing
Patch was applied. Closing. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
The server does not abort connection upon receiving a Client Hello message with malformed session_id field. Affects 1.0.1, 1.0.2 and master. In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is defined as opaque SessionID<0..32>; that means, that any SessionID longer than 32 bytes creates an incorrectly formatted Client Hello message, and as such, should be rejected. Reproducer: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt - nodes -batch openssl s_server -key localhost.key -cert localhost.crt In different console: pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-invalid-session-id.py -- 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 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 05:19:06PM +, Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible ClientHello as > well, but that seems to be easier to fix... or maybe it's time to just drop > that compatibility code for v1.1? I would love to have dropped that too, but 0.9.8 still sends such client hello. I think we're stuck with having to support that for a while longer. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 04:12:50PM +, Hubert Kario via RT wrote: > The server does not abort connection upon receiving a Client Hello > message with malformed session_id field. > > Affects 1.0.1, 1.0.2 and master. > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > defined as > > opaque SessionID<0..32>; > > that means, that any SessionID longer than 32 bytes creates an > incorrectly formatted Client Hello message, and as such, should be > rejected. Can be rejected, and perhaps even should be rejected, but I don't see a MUST here. It seems there's little harm in tolerating longer session ids (which never match, so are effectively ignored). So yes, I support adding a check for this (likely above the PACKET layer), but I don't think this has much urgency and likely should not be back-ported to stable releases. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 05:19:06PM +, Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible ClientHello as > well, but that seems to be easier to fix... or maybe it's time to just drop > that compatibility code for v1.1? I would love to have dropped that too, but 0.9.8 still sends such client hello. I think we're stuck with having to support that for a while longer. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote: > The server does not abort connection upon receiving a Client Hello > message with malformed session_id field. > > Affects 1.0.1, 1.0.2 and master. > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > defined as > > opaque SessionID<0..32>; > > that means, that any SessionID longer than 32 bytes creates an > incorrectly formatted Client Hello message, and as such, should be > rejected. Looking at the code in master, for non-v2 ClientHello messages the code uses the PACKET_get_length_prefixed_1() function to extract the SessionID, however I see no way to pass a maximum allowed length to it. I think a new function would have to be added to the PACKET_* interface (I can look into this). Haven't checked older branches yet. The problem most likely happens with SSLv2 backwards compatible ClientHello as well, but that seems to be easier to fix... or maybe it's time to just drop that compatibility code for v1.1? Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thursday 08 October 2015 17:19:06 Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible > ClientHello as well, but that seems to be easier to fix... or maybe > it's time to just drop that compatibility code for v1.1? There is quite a bit of clients that do send SSLv2 backwards compatible Client Hello, dropping it completely, even though it allows to relatively safely negotiate TLS connections, is probably going one step too far. I don't plan to work on SSLv2 Client Hello fuzzing in near future though. -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 06:14:00pm +, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote: > > On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote: > > > The server does not abort connection upon receiving a Client Hello > > > message with malformed session_id field. > > > > > > Affects 1.0.1, 1.0.2 and master. > > > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > > defined as > > > > > > opaque SessionID<0..32>; > > > > > > that means, that any SessionID longer than 32 bytes creates an > > > incorrectly formatted Client Hello message, and as such, should be > > > rejected. > > > > Looking at the code in master, for non-v2 ClientHello messages the code uses > > the PACKET_get_length_prefixed_1() function to extract the SessionID, > > however I > > see no way to pass a maximum allowed length to it. I think a new function > > would > > have to be added to the PACKET_* interface (I can look into this). Haven't > > checked older branches yet. > > So, it turns out the check was already performed, but this failure didn't > cause > the session to be aborted (the original PACKET was advanced anyway though, > even > is the session_id isn't actually extracted), I don't know if this was on > purpose though. Another thing to consider is that the client already aborts when an invalid session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER alert. My patch doesn't actually send any alert so the check should be moved earlier to allow an alert to be sent, if that is desired. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote: > > The server does not abort connection upon receiving a Client Hello > > message with malformed session_id field. > > > > Affects 1.0.1, 1.0.2 and master. > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > defined as > > > > opaque SessionID<0..32>; > > > > that means, that any SessionID longer than 32 bytes creates an > > incorrectly formatted Client Hello message, and as such, should be > > rejected. > > Looking at the code in master, for non-v2 ClientHello messages the code uses > the PACKET_get_length_prefixed_1() function to extract the SessionID, however > I > see no way to pass a maximum allowed length to it. I think a new function > would > have to be added to the PACKET_* interface (I can look into this). Haven't > checked older branches yet. So, it turns out the check was already performed, but this failure didn't cause the session to be aborted (the original PACKET was advanced anyway though, even is the session_id isn't actually extracted), I don't know if this was on purpose though. In any case I wrote a minimal patch that makes the tlsfuzzer test pass (it may even work for SSLv2 as well): https://github.com/openssl/openssl/pull/437 Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thursday 08 October 2015 17:37:12 Viktor Dukhovni wrote: > On Thu, Oct 08, 2015 at 04:12:50PM +, Hubert Kario via RT wrote: > > The server does not abort connection upon receiving a Client Hello > > message with malformed session_id field. > > > > Affects 1.0.1, 1.0.2 and master. > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > defined as > > > > opaque SessionID<0..32>; > > > > that means, that any SessionID longer than 32 bytes creates an > > incorrectly formatted Client Hello message, and as such, should be > > rejected. > > Can be rejected, and perhaps even should be rejected, but I don't > see a MUST here. It seems there's little harm in tolerating longer > session ids (which never match, so are effectively ignored). RFC 5246: decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network) (yes, it's not a MUST either, but I'm afraid that this was simply "too obvious" for designers of protocol) > So yes, I support adding a check for this (likely above the PACKET > layer), but I don't think this has much urgency and likely should > not be back-ported to stable releases. oh, sure, that particular problem isn't a serious issue, but I'm going through all fields and all messages so that we have full coverage (e.g. for valgrind) also, accepting bigger session id's means that the session cache code is exercised in ways that it usually isn't, that's not a good thing to happen (even if it handles them correctly, as it seems, defence in depth is a good idea anyway) -- 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: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)
On Thu, Oct 08, 2015 at 06:26:27pm +, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 06:14:00pm +, Alessandro Ghedini via RT wrote: > > On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote: > > > On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote: > > > > The server does not abort connection upon receiving a Client Hello > > > > message with malformed session_id field. > > > > > > > > Affects 1.0.1, 1.0.2 and master. > > > > > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > > > defined as > > > > > > > > opaque SessionID<0..32>; > > > > > > > > that means, that any SessionID longer than 32 bytes creates an > > > > incorrectly formatted Client Hello message, and as such, should be > > > > rejected. > > > > > > Looking at the code in master, for non-v2 ClientHello messages the code > > > uses > > > the PACKET_get_length_prefixed_1() function to extract the SessionID, > > > however I > > > see no way to pass a maximum allowed length to it. I think a new function > > > would > > > have to be added to the PACKET_* interface (I can look into this). Haven't > > > checked older branches yet. > > > > So, it turns out the check was already performed, but this failure didn't > > cause > > the session to be aborted (the original PACKET was advanced anyway though, > > even > > is the session_id isn't actually extracted), I don't know if this was on > > purpose though. > > Another thing to consider is that the client already aborts when an invalid > session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER > alert. > > My patch doesn't actually send any alert so the check should be moved earlier > to allow an alert to be sent, if that is desired. FYI, I just pushed another patch that does the above (moving the check and sending an alert) which I think is the best option (although, as Hubert pointed out, sending the decode_error alert is not a MUST). If that's ok with you, I can squash the two commits together and give them a better message, otherwise just ignore the second patch. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)
Fixed in master, 1.0.2 and 1.0.1. Closing ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)
On Fri, Oct 02, 2015 at 11:26:36am +, Hubert Kario via RT wrote: > Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client > Hello messages. > > If the client sends a Client Hello message with extensions.length field > equal to 0, but padded with bytes > FF01 0001 00 > then the Server Hello will contain the renegotiation_info extension. Yup, ssl_scan_clienthello_tlsext() extracts the length but then it doesn't do anything with it. I wrote a patch [0] that fixes this specific problem in master, but the tlsfuzzer script has a bunch of other failures. Incidentally, with my patch applied, the tlsfuzzer test takes a lot less time (like it's seconds faster), not quite sure if that's good or bad... Cheers [0] https://github.com/openssl/openssl/pull/421 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)
On Friday 02 October 2015 11:51:10 Alessandro Ghedini via RT wrote: > On Fri, Oct 02, 2015 at 11:26:36am +, Hubert Kario via RT wrote: > > Current git checkout of 1.0.1, 1.0.2 and master accept malformed > > Client Hello messages. > > > > If the client sends a Client Hello message with extensions.length > > field equal to 0, but padded with bytes > > FF01 0001 00 > > then the Server Hello will contain the renegotiation_info extension. > > Yup, ssl_scan_clienthello_tlsext() extracts the length but then it > doesn't do anything with it. > > I wrote a patch [0] that fixes this specific problem in master, but > the tlsfuzzer script has a bunch of other failures. Incidentally, > with my patch applied, the tlsfuzzer test takes a lot less time (like > it's seconds faster), not quite sure if that's good or bad... yes, all of the tests combined should finish in under 500ms on anything resembling a modern PC. any kind of "timed out" from tlsfuzzer means that the other side was expecting more data where it shouldn't have -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)
Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client Hello messages. If the client sends a Client Hello message with extensions.length field equal to 0, but padded with bytes FF01 0001 00 then the Server Hello will contain the renegotiation_info extension. This is in violation of RFC 3546 and RFC 4366 MUST: A server that supports the extensions mechanism MUST accept only client hello messages in either the original or extended ClientHello format, and (as for all other messages) MUST check that the amount of data in the message precisely matches one of these formats; if not then it MUST send a fatal "decode_error" alert. This overrides the "Forward compatibility note" in [TLS]. as well as the RFC 5246 MUST clause: A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert. Reproducer: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes -batch openssl s_server -key localhost.key -cert localhost.crt -www in other console: pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-truncating-of-client-hello.py -- 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 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)
On Fri, Oct 02, 2015 at 11:51:10am +, Alessandro Ghedini via RT wrote: > On Fri, Oct 02, 2015 at 11:26:36am +, Hubert Kario via RT wrote: > > Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client > > Hello messages. > > > > If the client sends a Client Hello message with extensions.length field > > equal to 0, but padded with bytes > > FF01 0001 00 > > then the Server Hello will contain the renegotiation_info extension. > > Yup, ssl_scan_clienthello_tlsext() extracts the length but then it doesn't do > anything with it. > > I wrote a patch [0] that fixes this specific problem in master, but the > tlsfuzzer script has a bunch of other failures. Incidentally, with my patch > applied, the tlsfuzzer test takes a lot less time (like it's seconds faster), > not quite sure if that's good or bad... I updated my patch as Matt suggested, and now all the failures seem to be gone. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
On Saturday 26 September 2015 01:02:15 Viktor Dukhovni wrote: > 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 more configurable than that to be worth the bother. > All sorts of "appliance" products with OpenSSL inside would > potentially some day pose a barrier to interoperability with clients > that send large HELLO messages. > > I should note that server side session state can also contain a > client certificate, which is then embedded in the session ticket. > So the outer limits of current practice are somewhat bigger. > > We could perhaps increase the limit from 16K to 32K bytes, just in > case that helps, and hope that the result does not expose servers > to significantly higher risk of DoS. > > Or raise the issue on the TLS WG. Are servers really expected > to support up to 128K or so of client HELLO? TLS 1.3 Client Hello will contain client key shares for _multiple_ key exchange methods (sending both DH 2048 and ECDH 256 is rather likely). Then we have session tickets, which for case with client certificates can easily be few kilobytes in size (there are "godzillacerts" that are bigger than 16KiB already out there). So I have to retract my initial "unlikely" and "never" and say that even for standard TLSv1.2 with commonly used extensions a Client Hello bigger than 16KiB is not out of the question. Client Hello messages of at least 2^16+σ MUST be accepted. Question is, how big the σ needs to be, likely 1KiB at the very least. I'd still say that it's just kicking the can down the road. -- 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: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4063] Re: [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
On Friday 25 September 2015 19:19:12 Kurt Roeckx via RT 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 require fairly large key > > sizes (large enough that protocol limitations itself are > > problematic), we may see Client Hellos larger than 16k in not so > > far future. > > 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 what the current version only > supports. For all other messages we should be able to tell what > the maximum size is. It was already raised on the IETF mailing list and nobody disagreed that any future Client Hello messages need to be compatible for previous protocol versions. And that was in context of TLS 1.3 and quantum resistant crypto. Finally, there are implementations that do follow the specification to the letter - e.g. Mozilla NSS. -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 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 checks for that. > > yes, it does place a limit of 2^14, but only on _records_, not handshake > messages that travel in those records > > > I think a proper fix would be to have all the ssl_get_message() calls > > changed to use the proper "max" parameter depending on the protocol > > version. > > As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly the > same as in they don't specify any upper size limit for the Handshake > protocol messages or Client Hello specifically other than the limits > enforced by the length fields themselves. > > Remember, the records are completely independent of messages that travel > through them, record layer is just there to multiplex the different > protocols that are required for TLS to work (handshake, CCS, application > data, etc.) Right. Some of the handshake messages do have a maximum length though (e.g. ChangeCipherSpace), so the maximum length check shouldn't be removed (as a sanity check). In the case of ClientHello, the minimal fix for the problem then is just a matter of finding the absolute maximum it can hold (which may as well be whatever the Handshake length field maximum value is). As a matter of test I changed the ssl_get_message() in ssl3_get_client_hello() to use 0xFF (uint24 max) as maximum size, and the tlsfuzzer failures went from 5 to 2, are all the tests supposed to pass? If so, then there's another problem as well. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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: > > > > 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 checks for that. > > > > yes, it does place a limit of 2^14, but only on _records_, not > > handshake messages that travel in those records > > > > > I think a proper fix would be to have all the ssl_get_message() > > > calls > > > changed to use the proper "max" parameter depending on the > > > protocol > > > version. > > > > As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly > > the same as in they don't specify any upper size limit for the > > Handshake protocol messages or Client Hello specifically other than > > the limits enforced by the length fields themselves. > > > > Remember, the records are completely independent of messages that > > travel through them, record layer is just there to multiplex the > > different protocols that are required for TLS to work (handshake, > > CCS, application data, etc.) > > Right. Some of the handshake messages do have a maximum length though > (e.g. ChangeCipherSpace), so the maximum length check shouldn't be > removed (as a sanity check). In the case of ClientHello, the minimal > fix for the problem then is just a matter of finding the absolute > maximum it can hold (which may as well be whatever the Handshake > length field maximum value is). the protocol states that the message must have all bytes accounted for if the implementation supports extensions, so if there is data trailing extensions array, its a protocol violation (I'm working on test cases for that right now) > 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 theory, but it does in practice, as extensions can only be 2^16 long, same for cipher suites, and you can't have data trailing the messages, so the actual size is limited to something closer 2^18, so if the client hello parser is correct, it will be limited by it > and the tlsfuzzer failures went from 5 to 2, are all the tests > supposed to pass? If so, then there's another problem as well. yes, there are also tests for record layer carrying the data in 1 byte chunks. The specification disallows only empty record layer messages. But it is less severe, as it doesn't cause a de-facto TLS extension intolerance. -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 theory, but it does in practice, as extensions can > only be 2^16 long, same for cipher suites, and you can't have data > trailing the messages, so the actual size is limited to something closer > 2^18, so if the client hello parser is correct, it will be limited by it Yeah, but OpenSSL first tries to "get" the handshake body and its length before parsing it (this is done by ssl3_get_message()). So the "max" argument is intended to be used, I imagine, as a sanity check: if the message exceeds that, then it's obviously broken and an "illegal parameters" alert is sent. This is done regardless of the message type, so the ClientHello parser has to do this as well. This max length check is not exactly smart (e.g. the max size of the SSLv3 ClientHello is very different from that of TLS) and could probably be removed completely, but I don't really know what the consequences of this would be. So the best next fix would simply be to provide an approximation of an absolute maximum length for the ClientHello (or just use 0xFF). I opened a pull request [0] with just this minimal fix. Anyone is very welcome to propose a better fix for this though. How trailing data is then handled is orthogonal to this problem (the length check doesn't really affect this). It might be that OpenSSL handles it correctly or not, I don't really know (and having the tlsfuzzer test for this will be very useful). Cheers [0] https://github.com/openssl/openssl/pull/413 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
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 (deliberate) > check for it. Each message in its call to ssl_get_message specifies > the max size. For ClientHello: > > n = s->method->ssl_get_message(s, >SSL3_ST_SR_CLNT_HELLO_B, >SSL3_ST_SR_CLNT_HELLO_C, >SSL3_MT_CLIENT_HELLO, >SSL3_RT_MAX_PLAIN_LENGTH, ); > > The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH > (=16384, or the max possible size that can fit into a single record). well, except that this doesn't include the message type and message length fields, so the message (from the point of view of record layer) is actually 2^14+4 bytes so it won't fit into a single record :) the actual maximum size is: 4 + # handshake protocol header 2 + # client_version 32 + # only valid length for random 1 + # length of session_id 32 + # maximum size for session_id 2 + # length of cipher suites 2^16-2 + # maximum length of cipher suites array 1 + # length of compression_methods 2^8-1 + # maximum length of compression methods 2 + # length of extensions 2^16-1 # maximum length of extensions = 131400 or 131396 without header > Every message has one of these defined. Some of them are quite > arbitrary values. > > E.g. for ServerHello > n = s->method->ssl_get_message(s, >SSL3_ST_CR_SRVR_HELLO_A, >SSL3_ST_CR_SRVR_HELLO_B, -1, 2, > ); > > Why 2? No idea. > > The same restriction exists in the state-machine-rewrite branches > because I'm ultra-cautious. entirely understandable > I am reluctant to remove an explicit check > like that without understanding why it's there in the first place. > Especially if its not breaking anything. Are we ever likely to > encounter a ClientHello > 16384 bytes? with actual TLSv1.2? likely "nothing" and "never". But the same could have been said about version number not being anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how well this turned out to be... 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 enough that protocol limitations itself are problematic), we may see Client Hellos larger than 16k in not so far future. -- 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 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected
-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 for it. Each message in its call to ssl_get_message specifies the max size. For ClientHello: n = s->method->ssl_get_message(s, SSL3_ST_SR_CLNT_HELLO_B, SSL3_ST_SR_CLNT_HELLO_C, SSL3_MT_CLIENT_HELLO, SSL3_RT_MAX_PLAIN_LENGTH, ); The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH (=16384, or the max possible size that can fit into a single record). Every message has one of these defined. Some of them are quite arbitrary values. E.g. for ServerHello n = s->method->ssl_get_message(s, SSL3_ST_CR_SRVR_HELLO_A, SSL3_ST_CR_SRVR_HELLO_B, -1, 2, ); Why 2? No idea. The same restriction exists in the state-machine-rewrite branches because I'm ultra-cautious. I am reluctant to remove an explicit check like that without understanding why it's there in the first place. Especially if its not breaking anything. Are we ever likely to encounter a ClientHello > 16384 bytes? Matt -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWBWlUAAoJENnE0m0OYESR0GUIAKPpYctFSqG7RVtPI8mKdw75 Ml+18+fOh4QE6RoKVLoBB3FglAZujZ8RMXlOZ6bivF8KrLygoAT6ECF/a0ee3kpk UAlYOY9HEHistlY+BeAs0jx2VsAKb10mO+Z+C6jV+Uql2GSTFqzrdGSdS6pxOuL1 EJr4WFh32sj+ApvTpDw6XVuvNypVpoEY5KeDj+4ZPKnQdp/TcoErLEzIgzIsGm7b FNXkpgTy8Xamr+S6afQYgNi6MOlHIIRlOXkDqkOyRpjHfqLU748EympIUkWNq8EZ dw8Sxk6PRTe9BqgtjX10benF3K7N9yuli2sLHoHFZvwTVqWvNqMgA2jyJIoCgM8= =bEaO -END PGP SIGNATURE- ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4063] Re: Client Hello longer than 2^14 bytes are rejected
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 (deliberate) > check for it. Each message in its call to ssl_get_message specifies > the max size. For ClientHello: > > n = s->method->ssl_get_message(s, >SSL3_ST_SR_CLNT_HELLO_B, >SSL3_ST_SR_CLNT_HELLO_C, >SSL3_MT_CLIENT_HELLO, >SSL3_RT_MAX_PLAIN_LENGTH, ); > > The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH > (=16384, or the max possible size that can fit into a single record). well, except that this doesn't include the message type and message length fields, so the message (from the point of view of record layer) is actually 2^14+4 bytes so it won't fit into a single record :) the actual maximum size is: 4 + # handshake protocol header 2 + # client_version 32 + # only valid length for random 1 + # length of session_id 32 + # maximum size for session_id 2 + # length of cipher suites 2^16-2 + # maximum length of cipher suites array 1 + # length of compression_methods 2^8-1 + # maximum length of compression methods 2 + # length of extensions 2^16-1 # maximum length of extensions = 131400 or 131396 without header > Every message has one of these defined. Some of them are quite > arbitrary values. > > E.g. for ServerHello > n = s->method->ssl_get_message(s, >SSL3_ST_CR_SRVR_HELLO_A, >SSL3_ST_CR_SRVR_HELLO_B, -1, 2, > ); > > Why 2? No idea. > > The same restriction exists in the state-machine-rewrite branches > because I'm ultra-cautious. entirely understandable > I am reluctant to remove an explicit check > like that without understanding why it's there in the first place. > Especially if its not breaking anything. Are we ever likely to > encounter a ClientHello > 16384 bytes? with actual TLSv1.2? likely "nothing" and "never". But the same could have been said about version number not being anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how well this turned out to be... 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 enough that protocol limitations itself are problematic), we may see Client Hellos larger than 16k in not so far future. -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected
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
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 0xFF (uint24 max) as maximum size, >> >> it doesn't have in theory, but it does in practice, as extensions can >> only be 2^16 long, same for cipher suites, and you can't have data >> trailing the messages, so the actual size is limited to something closer >> 2^18, so if the client hello parser is correct, it will be limited by it > > Yeah, but OpenSSL first tries to "get" the handshake body and its length > before > parsing it (this is done by ssl3_get_message()). So the "max" argument is > intended to be used, I imagine, as a sanity check: if the message exceeds > that, > then it's obviously broken and an "illegal parameters" alert is sent. This is > done regardless of the message type, so the ClientHello parser has to do this > as well. > > This max length check is not exactly smart (e.g. the max size of the SSLv3 > ClientHello is very different from that of TLS) and could probably be removed > completely, but I don't really know what the consequences of this would be. So > the best next fix would simply be to provide an approximation of an absolute > maximum length for the ClientHello (or just use 0xFF). I opened a pull > request [0] with just this minimal fix. Anyone is very welcome to propose a > better fix for this though. 0xff = 16777215 or 16Mb Allowing a ClientHello as big as this could enable a DoS attack. If I did my sums right I make the biggest possible valid ClientHello to be 131396. But should we allow something as big as this just because its theoretically possible? Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 0xFF (uint24 max) as maximum size, >> >> it doesn't have in theory, but it does in practice, as extensions can >> only be 2^16 long, same for cipher suites, and you can't have data >> trailing the messages, so the actual size is limited to something closer >> 2^18, so if the client hello parser is correct, it will be limited by it > > Yeah, but OpenSSL first tries to "get" the handshake body and its length > before > parsing it (this is done by ssl3_get_message()). So the "max" argument is > intended to be used, I imagine, as a sanity check: if the message exceeds > that, > then it's obviously broken and an "illegal parameters" alert is sent. This is > done regardless of the message type, so the ClientHello parser has to do this > as well. > > This max length check is not exactly smart (e.g. the max size of the SSLv3 > ClientHello is very different from that of TLS) and could probably be removed > completely, but I don't really know what the consequences of this would be. So > the best next fix would simply be to provide an approximation of an absolute > maximum length for the ClientHello (or just use 0xFF). I opened a pull > request [0] with just this minimal fix. Anyone is very welcome to propose a > better fix for this though. 0xff = 16777215 or 16Mb Allowing a ClientHello as big as this could enable a DoS attack. If I did my sums right I make the biggest possible valid ClientHello to be 131396. But should we allow something as big as this just because its theoretically possible? Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] AutoReply: Re: Client Hello longer than 2^14 bytes are rejected
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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
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 what the current version only > supports. For all other messages we should be able to tell what > the maximum size is. There's no such thing as "no limit". If the client HELLO retains its basic structure, it needs to retain the same limits. If the limits change, that's a new protocol message that is no longer an SSLv3/TLSv1.0 compatible client HELLO. The published limits from TLS 1.2 cannot change in TLS 1.3, if TLS 1.3 HELLO messages are to be understood by TLS 1.2 servers. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [EXTERNAL] Re: [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
> > 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 > > valid Client Hello bigger than 131396 bytes... > > The fact that the other libraries don't do this check at all suggests that > increasing the limit in OpenSSL (or even removing the limit completely) > shouldn't affect it negatively. Actually it suggests that they don't do their due diligence. If there is not a valid Hello message that is greater than 131396 bytes, then there is no reason to allow for one either. On the contrary, there is every reason to protect oneself from Godzillagrams. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
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 > enough that protocol limitations itself are problematic), we may see > Client Hellos larger than 16k in not so far future. 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 what the current version only supports. For all other messages we should be able to tell what the maximum size is. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
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 > enough that protocol limitations itself are problematic), we may see > Client Hellos larger than 16k in not so far future. 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 what the current version only supports. For all other messages we should be able to tell what the maximum size is. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 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 theory, but it does in practice, as extensions can > >> only be 2^16 long, same for cipher suites, and you can't have data > >> trailing the messages, so the actual size is limited to something closer > >> 2^18, so if the client hello parser is correct, it will be limited by it > > > > Yeah, but OpenSSL first tries to "get" the handshake body and its length > > before > > parsing it (this is done by ssl3_get_message()). So the "max" argument is > > intended to be used, I imagine, as a sanity check: if the message exceeds > > that, > > then it's obviously broken and an "illegal parameters" alert is sent. This > > is > > done regardless of the message type, so the ClientHello parser has to do > > this > > as well. > > > > This max length check is not exactly smart (e.g. the max size of the SSLv3 > > ClientHello is very different from that of TLS) and could probably be > > removed > > completely, but I don't really know what the consequences of this would be. > > So > > the best next fix would simply be to provide an approximation of an absolute > > maximum length for the ClientHello (or just use 0xFF). I opened a pull > > request [0] with just this minimal fix. Anyone is very welcome to propose a > > better fix for this though. > > 0xff = 16777215 or 16Mb > > Allowing a ClientHello as big as this could enable a DoS attack. > > If I did my sums right I make the biggest possible valid ClientHello to > be 131396. I updated my patch to use this value now. > But should we allow something as big as this just because its > theoretically possible? As a way of future-proofing OpenSSL (Hubert mentioned a few reasons) or just to be more standard-compliant I'd say yes, but it's obviously not an urgent problem. 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. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
(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 by that? As we've said with Matt, you can't create a valid Client Hello bigger than 131396 bytes... or do you mean that they accept malformed Client Hello messages? or that they do accept SSLv3 Client Hellos with arbitrary sized junk at the end? -- 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: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 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 theory, but it does in practice, as extensions > > >> can > > >> only be 2^16 long, same for cipher suites, and you can't have > > >> data > > >> trailing the messages, so the actual size is limited to something > > >> closer 2^18, so if the client hello parser is correct, it will > > >> be limited by it> > > > > Yeah, but OpenSSL first tries to "get" the handshake body and its > > > length before parsing it (this is done by ssl3_get_message()). So > > > the "max" argument is intended to be used, I imagine, as a sanity > > > check: if the message exceeds that, then it's obviously broken > > > and an "illegal parameters" alert is sent. This is done > > > regardless of the message type, so the ClientHello parser has to > > > do this as well. > > > > > > This max length check is not exactly smart (e.g. the max size of > > > the SSLv3 ClientHello is very different from that of TLS) and > > > could probably be removed completely, but I don't really know > > > what the consequences of this would be. So the best next fix > > > would simply be to provide an approximation of an absolute > > > maximum length for the ClientHello (or just use 0xFF). I > > > opened a pull request [0] with just this minimal fix. Anyone is > > > very welcome to propose a better fix for this though. > > > > 0xff = 16777215 or 16Mb > > > > Allowing a ClientHello as big as this could enable a DoS attack. > > > > If I did my sums right I make the biggest possible valid ClientHello > > to be 131396. > > I updated my patch to use this value now. embedding magic values is rather bad form. A define with extended comment describing how we arrived at this value would be much better -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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, 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 theory, but it does in practice, as extensions > > > >> can > > > >> only be 2^16 long, same for cipher suites, and you can't have > > > >> data > > > >> trailing the messages, so the actual size is limited to something > > > >> closer 2^18, so if the client hello parser is correct, it will > > > >> be limited by it> > > > > > Yeah, but OpenSSL first tries to "get" the handshake body and its > > > > length before parsing it (this is done by ssl3_get_message()). So > > > > the "max" argument is intended to be used, I imagine, as a sanity > > > > check: if the message exceeds that, then it's obviously broken > > > > and an "illegal parameters" alert is sent. This is done > > > > regardless of the message type, so the ClientHello parser has to > > > > do this as well. > > > > > > > > This max length check is not exactly smart (e.g. the max size of > > > > the SSLv3 ClientHello is very different from that of TLS) and > > > > could probably be removed completely, but I don't really know > > > > what the consequences of this would be. So the best next fix > > > > would simply be to provide an approximation of an absolute > > > > maximum length for the ClientHello (or just use 0xFF). I > > > > opened a pull request [0] with just this minimal fix. Anyone is > > > > very welcome to propose a better fix for this though. > > > > > > 0xff = 16777215 or 16Mb > > > > > > Allowing a ClientHello as big as this could enable a DoS attack. > > > > > > If I did my sums right I make the biggest possible valid ClientHello > > > to be 131396. > > > > I updated my patch to use this value now. > > embedding magic values is rather bad form. > A define with extended comment describing how we arrived at this value > would be much better Fair enough. Updated the patch again to do this. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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), 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 > valid Client Hello bigger than 131396 bytes... > > or do you mean that they accept malformed Client Hello messages? > or that they do accept SSLv3 Client Hellos with arbitrary sized junk at > the end? No and no. I meant that OpenSSL seems to be the only implementation (among the ones that I checked) to perform maximum length checks on handshake messages. That is, checking that the message doesn't exceed a pre-defined maximum length by only looking at the message type and length fields, before even trying to parse the message body. The fact that the other libraries don't do this check at all suggests that increasing the limit in OpenSSL (or even removing the limit completely) shouldn't affect it negatively. Cheers signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
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 require fairly large key sizes (large >> enough that protocol limitations itself are problematic), we may see >> Client Hellos larger than 16k in not so far future. > > 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 what the current version only > supports. For all other messages we should be able to tell what > the maximum size is. If the ClientHello message is longer than 131396 bytes then either we are under some kind attack, or it is in some future format that we do not understand and is not backwards compatible (a requirement of backwards compatibility would be that it is under or equal to that limit). Either way we should drop the message. My concern is whether we should have a limit that is less than that. A default s_client ClientHello on master at the moment is 364 bytes. A default ClientHello with a ticket is 556 bytes. The biggest ClientHello I can induce from s_client is one including a ticket and a cipher string of "ALL:@SECLEVEL=0" which leads to 618 bytes. I recognise that we are talking about future proofing; but the current limit of 16384 already gives us the ability to accept ClientHello's 26 times bigger than the biggest s_client can create today. That is significant room for future growth. On the other side of the coin handling very large ClientHello's is not without cost and risk. There is bandwidth consumption, memory consumption, CPU consumption handling any operations required from the ClientHello (e.g. decrypting an enormous SessionTicket) etc. We also have to bear in mind the OpenSSL doesn't necessarily just run on big powerful servers in datacentres. It can also runs in very resource constrained environments. We potentially open up our users to DoS attacks by attempting to accept these "godzillagram" (as someone called them) ClientHellos. Right now, today, if a server starts receiving ClientHello's that big then it is almost certainly an attack. Increasing the maximum size over what we have today increases the risk of attacks right now. Of course we don't know what the future will bring. I'm struggling to foresee a scenario where we have a vast explosion in the ciphersuites available (which is where a significant proportion of the "allowed" ClientHello size is allocated) - but I guess it could happen. Possibly more likely is some new extension(s) requiring very large extension data blocks. Still, whatever that extension is, it would have to be *massively* bigger than any extension we have today to blow the existing limit - and absolutely HUGE to go anywhere near 131396. The latency costs of managing such large ClientHello's would be significant so I am really finding it hard to see a future where ClientHello's get even close to approaching the kind of sizes we're talking about. So why would we open up our users today to increased risks for a future that seems quite unlikely? So, what I'm trying to say is it's a balancing act. We shouldn't just accept the biggest possible messages that we can just because that gives us the best interoperability for the future. There are other considerations. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
> 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: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected
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 more configurable than that to be worth the bother. All sorts of "appliance" products with OpenSSL inside would potentially some day pose a barrier to interoperability with clients that send large HELLO messages. I should note that server side session state can also contain a client certificate, which is then embedded in the session ticket. So the outer limits of current practice are somewhat bigger. We could perhaps increase the limit from 16K to 32K bytes, just in case that helps, and hope that the result does not expose servers to significantly higher risk of DoS. Or raise the issue on the TLS WG. Are servers really expected to support up to 128K or so of client HELLO? -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
reproducer:
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 -www
pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-record-layer-fragmentation.py
--
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
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 checks for that. AFAICT both SSLv3 and TLS implementations share the same ssl_accept() method (that is ssl3_accept()), which calls e.g. ssl3_get_client_key_exchange() which in turn calls the ssl_get_message() method (implemented by ssl3_get_message()) using SSL3_RT_MAX_PLAIN_LENGTH as maximum size. I think a proper fix would be to have all the ssl_get_message() calls changed to use the proper "max" parameter depending on the protocol version. The above applies to current master, I haven't checked the state machine rewrite branch yet. I can look into preparing a patch, if no one beats me to it. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected
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 place the limit at 2^14 or so bytes, so I think the > problem is that OpenSSL only checks for that. yes, it does place a limit of 2^14, but only on _records_, not handshake messages that travel in those records > I think a proper fix would be to have all the ssl_get_message() calls > changed to use the proper "max" parameter depending on the protocol > version. As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly the same as in they don't specify any upper size limit for the Handshake protocol messages or Client Hello specifically other than the limits enforced by the length fields themselves. Remember, the records are completely independent of messages that travel through them, record layer is just there to multiplex the different protocols that are required for TLS to work (handshake, CCS, application data, etc.) -- 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing
--strict-warnings started showing warnings for this today... My guess is that an error should be raised if these reads fail? I don't believe any of these are optional. PR: https://github.com/openssl/openssl/pull/360 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2801] Lost alert if client receives bad hello in dtls1_read_bytes
Patch applied. Many thanks. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Hello, OpenSSL!
Dear DevTeam, I am willing to contribute to The OpenSSL Project. How and where do I start? Here is my LinkedIn page: https://ee.linkedin.com/pub/andrejs-igumenovs/53/642/8b6 https://ee.linkedin.com/pub/andrejs-igumenovs/53/642/8b6 Thank you, Andrejs. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Hello, OpenSSL!
On 13/04/15 19:20, Andrejs Igumenovs wrote: Dear DevTeam, I am willing to contribute to The OpenSSL Project. How and where do I start? Here is a good place: https://wiki.openssl.org/index.php/Main_Page#Feedback_and_Contributions Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Pausing TLS negotiation after client hello
Hello All, I work with Apache Traffic Server. Many of our users use the SNI callback to select the certificate that the proxy will present to the client. This selection can take some time. Rather than blocking the callback thread, we would like to pause the negotiation from the SNI callback. After the certificate has been selected, SSL_accept can be called again to continue the processing. Looking at documentation and code, I did not see a way to do this, so I created a small patch on 1.0.1f. I'll say a few words about the patch below. But first, is there another way to achieve this in the existing 1.0.x API or the proposed 1.1 API? If not, is there broader interest in such an addition? The users within the Apache Traffic Server community would like to be able to use an un-patched openssl library. My patch is at https://issues.apache.org/jira/secure/attachment/12662757/openssl-sni.patch It adds SSL_TLSEXT_ERR_READ_AGAIN as another return value option for the SNI callback. On this return value, openssl stops the negotiation and marks the message to be reused. It does not signal an error to the client. The next time SSL_accept is called, the client hello message is processed again, and if the SNI callback returns the SSL_TLSEXT_ERR_OK, the negotiation will continue. Thanks for your attention, Susan Hinrichs ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Pausing TLS negotiation after client hello
On 1/23/2015 5:16 PM, Dr. Stephen Henson wrote: On Fri, Jan 23, 2015, Susan Hinrichs wrote: Hello All, I work with Apache Traffic Server. Many of our users use the SNI callback to select the certificate that the proxy will present to the client. This selection can take some time. Rather than blocking the callback thread, we would like to pause the negotiation from the SNI callback. After the certificate has been selected, SSL_accept can be called again to continue the processing. Looking at documentation and code, I did not see a way to do this, so I created a small patch on 1.0.1f. I'll say a few words about the patch below. But first, is there another way to achieve this in the existing 1.0.x API or the proposed 1.1 API? OpenSSL 1.0.2 has a certificate callback which can be used for both client and server certificates. It also supports non-blocking I/O so you can pause in the manner you describe. See: https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html Steve. Splendid! That looks like exactly what we need. Thank you for the pointer. Susan -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Pausing TLS negotiation after client hello
Hello All, I work with Apache Traffic Server. Many of our users use the SNI callback to select the certificate that the proxy will present to the client. This selection can take some time. Rather than blocking the callback thread, we would like to pause the negotiation from the SNI callback. After the certificate has been selected, SSL_accept can be called again to continue the processing. Looking at documentation and code, I did not see a way to do this, so I created a small patch on 1.0.1f. I'll say a few words about the patch below. But first, is there another way to achieve this in the existing 1.0.x API or the proposed 1.1 API? If not, is there broader interest in such an addition? The users within the Apache Traffic Server community would like to be able to use an un-patched openssl library. My patch is at https://issues.apache.org/jira/secure/attachment/12662757/openssl-sni.patch It adds SSL_TLSEXT_ERR_READ_AGAIN as another return value option for the SNI callback. On this return value, openssl stops the negotiation and marks the message to be reused. It does not signal an error to the client. The next time SSL_accept is called, the client hello message is processed again, and if the SNI callback returns the SSL_TLSEXT_ERR_OK, the negotiation will continue. Thanks for your attention, Susan Hinrichs ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Pausing TLS negotiation after client hello
On Fri, Jan 23, 2015, Susan Hinrichs wrote: Hello All, I work with Apache Traffic Server. Many of our users use the SNI callback to select the certificate that the proxy will present to the client. This selection can take some time. Rather than blocking the callback thread, we would like to pause the negotiation from the SNI callback. After the certificate has been selected, SSL_accept can be called again to continue the processing. Looking at documentation and code, I did not see a way to do this, so I created a small patch on 1.0.1f. I'll say a few words about the patch below. But first, is there another way to achieve this in the existing 1.0.x API or the proposed 1.1 API? OpenSSL 1.0.2 has a certificate callback which can be used for both client and server certificates. It also supports non-blocking I/O so you can pause in the manner you describe. See: https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Pausing TLS negotiation after client hello
On 1/23/2015 5:16 PM, Dr. Stephen Henson wrote: On Fri, Jan 23, 2015, Susan Hinrichs wrote: Hello All, I work with Apache Traffic Server. Many of our users use the SNI callback to select the certificate that the proxy will present to the client. This selection can take some time. Rather than blocking the callback thread, we would like to pause the negotiation from the SNI callback. After the certificate has been selected, SSL_accept can be called again to continue the processing. Looking at documentation and code, I did not see a way to do this, so I created a small patch on 1.0.1f. I'll say a few words about the patch below. But first, is there another way to achieve this in the existing 1.0.x API or the proposed 1.1 API? OpenSSL 1.0.2 has a certificate callback which can be used for both client and server certificates. It also supports non-blocking I/O so you can pause in the manner you describe. See: https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html Steve. Splendid! That looks like exactly what we need. Thank you for the pointer. Susan -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
How to send SSLv3 client-hello by using SSLv23_method
How to send SSLv3 client-hello by using SSLv23_method? I don't want to disable any protocol except SSLv2 don't want to use SSLv3_method. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3437] Bug in TLS Client Hello CipherSuite List
Hi,
I've found a bug in the Client Hello cipher suites list corresponding to RFC
2246. Always the last cipher suite in the list contains an additional byte
0xFF, so the rest of the record cannot be read correctly and connections, which
use the following Client Hello Extensions, fail.
I'm note sure, in which version(s) and since this bug is in. I only see, that
connections will not work, as soon as the request goes through an web proxy
with https inspection which use openssl. I tested with different comercial
products, request which goes through a web proxy which do not use openssl (e.g
Microsoft TMG) works fine. So I guess, this additional byte is the reason for
broken connections.
All of the tested web proxy products are patched because of the heart bleeding
bug.
Example: This is a TLS Rec Layer-1 which contains the additional byte 0xFF on
position 007D:
16 03 01 00 E4 01 00 00 E0 03 01 83 1E 08 12 F6
0010 02 39 AC 34 43 6F 43 E3 FC 67 6F F8 38 6D E3 19
0020 FC 80 E1 8D 5C CF EE FE 61 3F AF 00 00 50 C0 14
0030 C0 0A C0 22 C0 21 00 39 00 38 00 88 00 87 C0 0F
0040 C0 05 00 35 00 84 C0 12 C0 08 C0 1C C0 1B 00 16
0050 00 13 C0 0D C0 03 00 0A C0 13 C0 09 C0 1F C0 1E
0060 00 33 00 32 00 45 00 44 C0 0E C0 04 00 2F 00 41
0070 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 FF 02 01
0080 00 00 66 00 00 00 19 00 17 00 00 14 77 65 62 63
0090 6F 6E 66 2E 63 6F 6E 6E 65 63 74 69 73 2E 63 68
00A0 00 0B 00 04 03 00 01 02 00 0A 00 34 00 32 00 0E
00B0 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 0A 00 16
00C0 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05
00D0 00 12 00 13 00 01 00 02 00 03 00 0F 00 10 00 11
00C0 00 23 00 00 00 0F 00 01 01
The 0xFF on position 007D should not be there, only then, the rest of the
record can interpreted correctly.
Here you find the whole tree of the wrong ClientHello (with 0xFF): Have a look
at the last TLSCipherSuites and the following bytes:
Frame: Number = 5, Captured Frame Length = 299, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP
(IPv4),DestinationAddress:[00-0C-29-AA-3E-0C],SourceAddress:[00-22-55-7E-D2-E7]
+ Ipv4: Src = 193.134.161.73, Dest = 91.209.53.40, Next Protocol = TCP, Packet
ID = 49379, Total IP Length = 285
+ Tcp: Flags=...AP..., SrcPort=37948, DstPort=HTTPS(443), PayloadLen=233,
Seq=1755423924 - 1755424157, Ack=4227022623, Win=29 (scale factor 0x9) = 14848
TLSSSLData: Transport Layer Security (TLS) Payload Data
- TLS: TLS Rec Layer-1 HandShake: Client Hello. Encrypted Handshake Message.
- TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
- Version: TLS 1.0
Major: 3 (0x3)
Minor: 1 (0x1)
Length: 228 (0xE4)
- SSLHandshake: SSL HandShake Encrypted Handshake Message
HandShakeType: ClientHello(0x01)
Length: 224 (0xE0)
- ClientHello: TLS 1.0
+ Version: TLS 1.0
+ RandomBytes:
SessionIDLength: 0 (0x0)
CipherSuitesLength: 80
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
+ TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA{ 0xC0,0x0A }
+ TLSCipherSuites: TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA{ 0xC0,0x22 }
+ TLSCipherSuites: TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x21 }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA{ 0x00, 0x39 }
+ TLSCipherSuites: TLS_DHE_DSS_WITH_AES_256_CBC_SHA{ 0x00, 0x38 }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA { 0x00, 0x88 }
+ TLSCipherSuites: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA { 0x00, 0x87 }
+ TLSCipherSuites: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x0F }
+ TLSCipherSuites: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x05 }
+ TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA{ 0x00, 0x35 }
+ TLSCipherSuites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA { 0x00, 0x84 }
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x12 }
+ TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x08 }
+ TLSCipherSuites: TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA { 0xC0,0x1C }
+ TLSCipherSuites: TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x1B }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA{ 0x00,0x16}
+ TLSCipherSuites: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA{ 0x00,0x13 }
+ TLSCipherSuites: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x0D }
+ TLSCipherSuites: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA{ 0xC0,0x03 }
+ TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
+ TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA{ 0xC0,0x09 }
+ TLSCipherSuites: TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA{ 0xC0,0x1F }
+ TLSCipherSuites: TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA{ 0xC0,0x1E }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA{ 0x00, 0x33 }
+ TLSCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
Re: [openssl.org #3437] Bug in TLS Client Hello CipherSuite List
On Sun, Jul 06, 2014 at 10:18:29AM +0200, Kaufmann Stephan via RT wrote:
- TLSCipherSuites: Unknown Cipher { 0x00,0xFF }
That is TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Hope, I could explain the problem and you can fix it soon and the fix will be
applied soon to all web proxies...
I don't see a problem. Your tool doesn't know about some
cipher as far as I can see.
I'm not sure what is exactly in between, but as far as I can see
that is causing the problem and there is nothing wrong with the
handshake.
The was introduced as part of the secure renegiotation. See
RFC 5746.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3437] Bug in TLS Client Hello CipherSuite List
Copying Kurt Roeckx response to this below (which only went to the openssl-dev
list, and not to RT).
Based on Kurt's response I am closing this ticket for now. Please re-open by
responding to this email if you still think this is a defect.
Matt
On Sun, Jul 06, 2014 at 10:18:29AM +0200, Kaufmann Stephan via RT wrote:
- TLSCipherSuites: Unknown Cipher {
0x00,0xFF }
That is TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Hope, I could explain the problem and you can fix it soon and the fix
will be applied soon to all web proxies...
I don't see a problem. Your tool doesn't know about some
cipher as far as I can see.
I'm not sure what is exactly in between, but as far as I can see
that is causing the problem and there is nothing wrong with the
handshake.
The was introduced as part of the secure renegiotation. See
RFC 5746.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2116] [OpenSSL 0.9.8k] client auth : Exit: error in SSLv3 read client hello A
somebody fixed something, not sure hwne. but old release old ticket and we'd have heard if it was still broken. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2828] TLS 1.1 and 1.2 client - invalid Client Hello during renegotiation
No further reports, marking as resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3374] Do not advertise ECC ciphersuites in SSLv2 client hello
On Út, 2014-06-03 at 16:41 +, Viktor Dukhovni wrote: On Tue, Jun 03, 2014 at 06:01:03PM +0200, Tomas Mraz via RT wrote: openssl advertises ECC ciphersuites in SSLv2 client hello if ssl23 method is used. This is incorrect because the TLS extensions that indicate supported curves and point formats cannot be sent in SSLv2 client hello. The attached patch ensures that no ECC ciphersuites are sent in SSLv2 client hello. This looks about right, where do you still use SSLv2? Nowadays, you should probably have SSLv2 disabled. SSLv2 is disabled by default, however when you use the ALL cipher list which is of course something you should not do but it happened in perl LDAP module the SSLv2 ciphers are added to the cipherlist and SSLv2 client hello is used. I agree that once we break API/ABI compatibility we should remove SSLv2 support altogether. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3374] Do not advertise ECC ciphersuites in SSLv2 client hello
On Wed, Jun 04, 2014 at 10:45:59AM +0200, Tomas Mraz wrote: SSLv2 is disabled by default, however when you use the ALL cipher list which is of course something you should not do but it happened in perl LDAP module the SSLv2 ciphers are added to the cipherlist and SSLv2 client hello is used. In Postfix, I use the ALL cipherlist, but I also pass SSL_OP_NO_SSLv2 to SSL_CTX_set_options(). If you can append exclusions to the cipherlist, you can use 'ALL:...:!SSLv2'. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3374] Do not advertise ECC ciphersuites in SSLv2 client hello
On St, 2014-06-04 at 13:03 +, Viktor Dukhovni wrote: On Wed, Jun 04, 2014 at 10:45:59AM +0200, Tomas Mraz wrote: SSLv2 is disabled by default, however when you use the ALL cipher list which is of course something you should not do but it happened in perl LDAP module the SSLv2 ciphers are added to the cipherlist and SSLv2 client hello is used. In Postfix, I use the ALL cipherlist, but I also pass SSL_OP_NO_SSLv2 to SSL_CTX_set_options(). If you can append exclusions to the cipherlist, you can use 'ALL:...:!SSLv2'. I know that. We are fixing perl-LDAP to not use ALL at all and stick with the default. However we will be patching openssl anyway for any other 3rd party cases where they intentionally or not enable SSLv2 client hello. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3374] Do not advertise ECC ciphersuites in SSLv2 client hello
On Tue, Jun 03, 2014 at 06:01:03PM +0200, Tomas Mraz via RT wrote:
openssl advertises ECC ciphersuites in SSLv2 client hello if ssl23
method is used. This is incorrect because the TLS extensions that
indicate supported curves and point formats cannot be sent in SSLv2
client hello. The attached patch ensures that no ECC ciphersuites are
sent in SSLv2 client hello.
This looks about right, where do you still use SSLv2? Nowadays,
you should probably have SSLv2 disabled.
diff -up openssl-1.0.1e/ssl/s23_lib.c.ssl2noec openssl-1.0.1e/ssl/s23_lib.c
--- openssl-1.0.1e/ssl/s23_lib.c.ssl2noec 2013-02-11 16:26:04.0
+0100
+++ openssl-1.0.1e/ssl/s23_lib.c 2014-05-06 15:51:54.053293674 +0200
@@ -107,6 +107,13 @@ int ssl23_put_cipher_by_char(const SSL_C
long l;
/* We can write SSLv2 and SSLv3 ciphers */
+ /* but no ECC ciphers */
+ if (c-algorithm_mkey == SSL_kECDHr ||
+ c-algorithm_mkey == SSL_kECDHe ||
+ c-algorithm_mkey == SSL_kEECDH ||
+ c-algorithm_auth == SSL_aECDH ||
+ c-algorithm_auth == SSL_aECDSA)
+ return 0;
if (p != NULL)
{
l=c-id;
--
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
signature_algorithms in client hello in FIPS mode
OpenSSL removes the RSA/MD5 combination from the tls12_sigalgs[] table in the
tls12_get_req_sig_algs() function when FIPS mode is in effect. (This reduced
set of signature/hash algorithm pairs is used to fill in the
supported_signature_algorithms field in the TLS 1.2 Certificate Request
message when client authentication is in play.)
Shouldn't that same logic apply to ssl_add_clienthello_tlsext() and the
signature_algorithms extension when FIPS mode is in effect?
if (TLS1_get_client_version(s) = TLS1_2_VERSION)
{
if ((size_t)(limit - ret) sizeof(tls12_sigalgs) + 6)
return NULL;
s2n(TLSEXT_TYPE_signature_algorithms,ret);
s2n(sizeof(tls12_sigalgs) + 2, ret);
s2n(sizeof(tls12_sigalgs), ret);
- memcpy(ret, tls12_sigalgs, sizeof(tls12_sigalgs));
+ len = tls12_get_req_sig_algs(s, ret);
- ret += sizeof(tls12_sigalgs);
+ ret += len;
}
Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Hello
wow this is pretty crazy you should check it out http://www.finance15dynews.net/biz/?read=5845066 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Hello
wow this is amazing look into this http://www.finance15elnews.net/biz/?news=1625431 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2828] TLS 1.1 and 1.2 client - invalid Client Hello during renegotiation
Greetings, The Tor project has uncovered an issue with the new support for TLS 1.1 and 1.2 in OpenSSL 1.0.1. It is reproducible with the s_client utility. There does not appear to be any obvious security impact, but it does represent a failure to interoperate. The bug relates to the implementation of renegotiation (both client- and server-initiated). If an OpenSSL client has negotiated the use of TLS = 1.1, when he sends the renegotiating Client Hello it carries the wrong version number on the handshake record. It always has TLS 1.0 instead of the actual negotiated version current on the connection. This behavior would appear to be in conflict with RFC 5246 which states in section 7.4.1. Hello Messages: The current connection state is used for renegotiation messages. When the problem occurs, this error is generated on both the client and the server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:340 Attached is a pcap of the problem occurring with s_client and s_server and a patch that seems to fix it. As the record version field is sent in the clear, decryption of the pcap isn't necessary to see the problem. In response to failed connection attempts, the short-term workaround being deployed by the Tor project is simply to disable the use of TLS 1.1 and 1.2. In order for this protocol support to be un-disabled there will likely need be a positive indication of the fix available at compile time. As there are some widely used Linux distros that are fond of backporting patches without incrementing the version number, ideally they could get a preprocessor definition to indicate TLS 1.0 was safe to use with renegotiation. Let me know if I can provide any additional info. Thanks, - Marsh For reference, the Tor trac ticket: https://trac.torproject.org/projects/tor/ticket/6033 openssl-1.0.1c-client-initiated-renego.pcap Description: application/vnd.tcpdump.pcap diff -u openssl-1.0.1c/ssl/s3_pkt.c openssl-1.0.1c-patch/ssl/s3_pkt.c --- openssl-1.0.1c/ssl/s3_pkt.c 2012-04-17 08:20:19.0 -0500 +++ openssl-1.0.1c-patch/ssl/s3_pkt.c 2012-06-03 00:37:53.656411137 -0500 @@ -740,10 +740,11 @@ wr-type=type; *(p++)=(s-version8); - /* Some servers hang if iniatial client hello is larger than 256 + /* Some servers hang if initial client hello is larger than 256 * bytes and record version number TLS 1.0 */ if (s-state == SSL3_ST_CW_CLNT_HELLO_B + !SSL_renegotiate_pending(s) TLS1_get_version(s) TLS1_VERSION) *(p++) = 0x1; else diff -u openssl-1.0.1c/ssl/ssl.h openssl-1.0.1c-patch/ssl/ssl.h --- openssl-1.0.1c/ssl/ssl.h 2012-04-25 18:08:44.0 -0500 +++ openssl-1.0.1c-patch/ssl/ssl.h 2012-06-03 01:07:22.456505267 -0500 @@ -221,6 +221,9 @@ #define SSL_MAX_KEY_ARG_LENGTH 8 #define SSL_MAX_MASTER_KEY_LENGTH 48 +/* Early TLS 1.1 and 1.2 support in OpenSSL didn't allow renegotiation. + * This definition indicates at compile time that renegotiation support + * support is available in these protocol versions. */ +#define SSL_TLSV1_1_AND_V1_2_CAN_RENEGOTIATE 1 /* These are used to specify which ciphers to use and not to use */
[openssl.org #2828] TLS 1.1 and 1.2 client - invalid Client Hello during renegotiation
[ma...@extendedsubset.com - Mon Jun 04 00:23:30 2012]: Greetings, The Tor project has uncovered an issue with the new support for TLS 1.1 and 1.2 in OpenSSL 1.0.1. It is reproducible with the s_client utility. There does not appear to be any obvious security impact, but it does represent a failure to interoperate. This should fix it: http://cvs.openssl.org/chngview?cn=22567 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2801] Lost alert if client receives bad hello in dtls1_read_bytes
This patch fixes lost alert in dtls1_read_bytes in d1_pkt.c:1024.
Assigning value to al is useless unless goto jumps to f_err label.
Index: ssl/d1_pkt.c
===
RCS file: /v/openssl/cvs/openssl/ssl/d1_pkt.c,v
retrieving revision 1.55
diff -u -r1.55 d1_pkt.c
--- ssl/d1_pkt.c 9 Mar 2012 15:52:33 - 1.55
+++ ssl/d1_pkt.c 24 Apr 2012 12:32:03 -
@@ -1021,7 +1021,7 @@
{
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_DTLS1_READ_BYTES,SSL_R_BAD_HELLO_REQUEST);
- goto err;
+ goto f_err;
}
/* no need to check sequence number on HELLO REQUEST messages */
hello my dear
it is really best place for us i had try , it is truth and service is very good fast ship and best quality hope you can try too here is : www.bestsker.com enjoy yourself
[openssl.org #2116] [OpenSSL 0.9.8k] client auth : Exit: error in SSLv3 read client hello A
Hi, Apparently since the openssl CVE-2009-3555 fix, I am having trouble with client authentication in mod_ssl which seems totally broken. It fails with : Exit: error in SSLv3 read client hello A error. There are more details about my investigation on the openSUSE bug tracker : https://bugzilla.novell.com/show_bug.cgi?id=558176 At least another person has reported the problem on the mailing list : http://www.mail-archive.com/openssl-us...@openssl.org/msg59562.html It is so specific that I don't know how to help more, but I am at your disposal for more testing. Regards, Jean-Christophe signature.asc Description: PGP signature
getting/setting challenge bits from Client Hello?
Hi, all. I have a need to retrieve the challenge bits from a Client Hello message I receive and set them in a Client Hello message I send. Why? I have an (intentional) MITM SSL proxy where two sessions (client-proxy and proxy-server) are set up so that traffic can be decrypted and examined before being sent to the real client. The proxy builds a new server cert chain by (re-)signing the server's cert with its own CA cert (that the client trusts - there is no tomfoolery here: the proxy serves to inspect encrypted traffic on the client's behalf). Here's the problem: sometimes we want to just stitch the client and server directly, without going through the proxy. Some clients do not offer the opportunity to import a new trusted CA cert (generally for specific applications communicating with application-specific servers, so they have hard-coded trusted certs). We'd like to do this AFTER receiving the Server Certificate, but BEFORE completing the DH exchange. The idea is as follows: 1) Accept the Client Hello from the client, with version, challenge bytes, and cipher suite. 2) Set the proxy Client Hello with the same version, challenge bytes, and cipher suite. 3) Have the proxy negotiate with the server until a server cert chain is received. Remember the Server Hello and Server Cert Chain. 4) Examine the Server Cert and decide to proxy (step 5) or bypass (step 6) 5) Proxy: operate as usual, resign received server cert and set it in client-proxy SSL session. Decrypt and Reencrypt traffic as normal. 6) The Proxy-Server SSL instance has sent the SAME Client Hello to the server that the Client-Proxy SSL instance received. The two SSL instances have the same internal state.[1] Send the remembered Server Hello and Server Cert Chain directly to the client and proxy at the TCP layer only. [1] This should work so long as no part of the Client Hello is cryptographically related to a secret that the Client has. If it were, the proxy would not know it and we could not proxy at the decrypted SSL layer. The general requirement is to be able to obtain the state of one SSL session and what received packet put it in that state and initialize another SSL session to the previous state necessary for it to advance to the same state after sending the same packet. Any ideas about where to look at hooking the necessary callbacks in to get such internal state changes and to set such internal states?
RE: getting/setting challenge bits from Client Hello?
I think I found the state callbacks and structure members I need. Sorry for the spam. From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Rene Hollan Sent: Tuesday, September 01, 2009 2:59 PM To: openssl-dev@openssl.org Subject: getting/setting challenge bits from Client Hello? Hi, all. I have a need to retrieve the challenge bits from a Client Hello message I receive and set them in a Client Hello message I send. Why? I have an (intentional) MITM SSL proxy where two sessions (client-proxy and proxy-server) are set up so that traffic can be decrypted and examined before being sent to the real client. The proxy builds a new server cert chain by (re-)signing the server's cert with its own CA cert (that the client trusts - there is no tomfoolery here: the proxy serves to inspect encrypted traffic on the client's behalf). Here's the problem: sometimes we want to just stitch the client and server directly, without going through the proxy. Some clients do not offer the opportunity to import a new trusted CA cert (generally for specific applications communicating with application-specific servers, so they have hard-coded trusted certs). We'd like to do this AFTER receiving the Server Certificate, but BEFORE completing the DH exchange. The idea is as follows: 1) Accept the Client Hello from the client, with version, challenge bytes, and cipher suite. 2) Set the proxy Client Hello with the same version, challenge bytes, and cipher suite. 3) Have the proxy negotiate with the server until a server cert chain is received. Remember the Server Hello and Server Cert Chain. 4) Examine the Server Cert and decide to proxy (step 5) or bypass (step 6) 5) Proxy: operate as usual, resign received server cert and set it in client-proxy SSL session. Decrypt and Reencrypt traffic as normal. 6) The Proxy-Server SSL instance has sent the SAME Client Hello to the server that the Client-Proxy SSL instance received. The two SSL instances have the same internal state.[1] Send the remembered Server Hello and Server Cert Chain directly to the client and proxy at the TCP layer only. [1] This should work so long as no part of the Client Hello is cryptographically related to a secret that the Client has. If it were, the proxy would not know it and we could not proxy at the decrypted SSL layer. The general requirement is to be able to obtain the state of one SSL session and what received packet put it in that state and initialize another SSL session to the previous state necessary for it to advance to the same state after sending the same packet. Any ideas about where to look at hooking the necessary callbacks in to get such internal state changes and to set such internal states?
Re: TLS hello extensions and supplemental data patch
Hi, I've wanted to test the TLS Extension from this framework by using the Hello World example that comes along with the toolkit. My problem is that when i run the small client - server that i have created the callbacks are not called. Have i missed something? I have attached the code of the client and the server and this is the output from the client: http://www.nabble.com/file/p23359792/wclient.c wclient.c http://www.nabble.com/file/p23359792/wserver.c wserver.c [DBG] DAA-TLS Initialization [DBG] DAA-TLS enabled HTTP/1.0 200 OK Server: EKRServer Server test page Davide Vernizzi-3 wrote: On Wed, 2009-04-22 at 04:42 -0700, nhack wrote: Can someone send me the patch or the download link for this extension? Here it comes. You can find the software at this address: http://security.polito.it/opentc/daa-toolkit-preview/ In the package you can find a snapshot of OpenSSL and the patch. There is also a README with installation instructions. The Package is a part of a larger one. We had to remove a part of the original package because some license issues are not clear yet. See http://security.polito.it/opentc/daa-toolkit-preview/README.txt for further information. Note that the README is not modified; therefore you will find instructions about software that is not present in the package. Finally, there's a document that explains how to write new extensions using the general framework. Again, this document is part of a larger documentation that also covers the software that we had to remove. If you are interested in the whole package, it should be public in late June. Until that date, please consider this software and documentation as a preview. -- Davide -- View this message in context: http://www.nabble.com/TLS-hello-extensions-and-supplemental-data-patch-tp23174619p23359792.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TLS hello extensions and supplemental data patch
On Wed, 2009-04-22 at 04:42 -0700, nhack wrote: Can someone send me the patch or the download link for this extension? Here it comes. You can find the software at this address: http://security.polito.it/opentc/daa-toolkit-preview/ In the package you can find a snapshot of OpenSSL and the patch. There is also a README with installation instructions. The Package is a part of a larger one. We had to remove a part of the original package because some license issues are not clear yet. See http://security.polito.it/opentc/daa-toolkit-preview/README.txt for further information. Note that the README is not modified; therefore you will find instructions about software that is not present in the package. Finally, there's a document that explains how to write new extensions using the general framework. Again, this document is part of a larger documentation that also covers the software that we had to remove. If you are interested in the whole package, it should be public in late June. Until that date, please consider this software and documentation as a preview. -- Davide smime.p7s Description: S/MIME cryptographic signature
TLS hello extensions and supplemental data patch
Can someone send me the patch or the download link for this extension? Thank you! Marius -- View this message in context: http://www.nabble.com/TLS-hello-extensions-and-supplemental-data-patch-tp23174619p23174619.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
How to debug error in Client-Server hello
Hi All, I'm fairly new at SSL... I was trying to use the openSSL with eXosip/osip, and I see that the client side makes a Client Hello ( when server side seems to be resetting ). The observation is using WireShark ... This is when I try to execute tcp-tls and send SIP packets over to the server... But if I try to send udp-tls, thing seem to work fine. Application payload get across correctly ... By using some of the example code from Network Security with OpenSSL, and there I could set secured connection, but don't see client hello and sever hello, so I need to find some example code to do the same with just openssl package... then probably I could nail down if there is a bug in the eXosip/sip engine ... Thanks in adv. for any lead ... -pro
hello
i m running the openssl 3 commands : openssl genrsa -out C:\Documents and Settings\bon\Desktop\openssl\test1\temp-key.pem 1024 openssl rsa -passin pass:123 -in C:\Documents and Settings\bon\Desktop\openssl\test1\temp-key.pem -out C:\Documents and Settings\bon\Desktop\openssl\test1\server-key.pem openssl req -passin pass:123 -batch -new -x509 -config C:\Documents and Settings\bon\Desktop\openssl\openssl.cnf -days 1825 -key C:\Documents and Settings\bon\Desktop\openssl\test1\server-key.pem -out C:\Documents and Settings\bon\Desktop\openssl\ test1\server-cert.pem and I would like to know 2 things : 1. how can I create the.rnd file at temp folder and not under C:\ 2. how can I change the value of : commonName_default = local_machine_name whice is located at : [ req_distinguished_name ] to hold the computer name . Thanks in advance Ohad ** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** **
Re: hello
Hi Ohad, 'hello' is not a very appropriate subject for list posts and I would like to know 2 things : 1.how can I create the.rnd file at temp folder and not under C:\ 2.how can I change the value of : commonName_default = local_machine_name whice is located at : [ req_distinguished_name ] to hold the computer name . you can change these things in your openssl.cnf; 1.) --- RANDFILE= $ENV::HOME/.rnd +++ RANDFILE= $ENV::TEMP/.rnd 2.) commonName_default = $ENV::USERDOMAIN HTH, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How long is the server hello header?
Richard Kao wrote: Hi I'm a newbie to openssl. This is actually a question about concept, and I hope this is the place I can ask this question. Basically speaking, I'm trying to get the pointer to Certificate in a raw Server Hello packet on the Client side. So far when the client receives a Server Hello, I can get the pointer to the first byte of Secure Socket Layer, from there I see there is a server hello header before the actual Certificate data. In order to get the pointer to Certificate, I need to learn the structure (length) of this server hello header. Which part of code in Openssl I can learn from for reference purpose? Maybe it'll be easier to discern the structure of the msgs from the struct definitions in rfc2246. -jb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
How long is the server hello header?
Hi I'm a newbie to openssl. This is actually a question about concept, and I hope this is the place I can ask this question. Basically speaking, I'm trying to get the pointer to Certificate in a raw Server Hello packet on the Client side. So far when the client receives a Server Hello, I can get the pointer to the first byte of Secure Socket Layer, from there I see there is a server hello header before the actual Certificate data. In order to get the pointer to Certificate, I need to learn the structure (length) of this server hello header. Which part of code in Openssl I can learn from for reference purpose? Thanks, Rick _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: version 2 is used for Client Hello when version 3 was requested in client code
On Thu, May 12, 2005 at 09:40:38AM +0200, Thomas wrote: Am Freitag, 13. Mai 2005 20:32 schrieb Bodo Moeller: On Wed, May 11, 2005 at 02:14:23PM +0200, Thomas Biege wrote: You see I use SSLv23_method() and later SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2); to disable SSLv2 support. Is it normal that the Client Hello message is SSLv2 and later TLS is used? Yes. In the past this used to be necessary because some SSL 3.0 implementations were confused by seeing TLS 1.0 records in the Client Hello. But now these issues should be history. Why wasn't SSLv3(.0) be used? Or will only headers of SSLv3(.1) be identified as real SSLv3? I am confused a bit b/c everyone tells you that SSLv2 isn't secure and so usage of it should be avoided... and then it was used silently. Maybe its insecurity doesn't matter in this early stage. With SSL_OP_NO_SSLv2, SSL 2.0 was never used, so its security problems did not apply. The SSL 2.0 compatible client hello message that was generated by SSLv23_client_method() is just a different way of arranging essentially the same information that occurs in an SSL 3.0 or TLS 1.0 client hello message. (You just can't list compression techniques in the SSL 2.0 format, and you can't include TLS extensions. TLS extensions are not yet supported by OpenSSL, though.) When the SSL 2.0 compatible client hello is *not* used, the data sent by the client contains two version numbers: One is the version number in the record headers (the SSL 2.0 format does not have anything like this); the second is the version number given in the actual client hello message (the maximum protocol version supported by the client). In the past when many servers supported only SSL 2.0 and 3.0 but not TLS 1.0, setting the version number in the record header to 3.1 (for TLS 1.0) could lead to some servers rejecting such packets because, not recognizing the record header format, they did not even look at the actual client hello message -- clients had to use the SSL 2.0 format to avoid this server bug. By now, this is no longer a problem, and even when clients use a nonsense version number such as 3.42, servers will simply reply with the maximum protocol version that they support (i.e., either TLS 1.0 or SSL 3.0). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: version 2 is used for Client Hello when version 3 was requested in client code
Why wasn't SSLv3(.0) be used? Or will only headers of SSLv3(.1) be identified as real SSLv3? I am confused a bit b/c everyone tells you that SSLv2 isn't secure and so usage of it should be avoided... and then it was used silently. Maybe its insecurity doesn't matter in this early stage. With SSL_OP_NO_SSLv2, SSL 2.0 was never used, so its security problems did not apply. The SSL 2.0 compatible client hello message that was generated by SSLv23_client_method() is just a different way of arranging essentially the same information that occurs in an SSL 3.0 or TLS 1.0 client hello message. (You just can't list compression techniques in the SSL 2.0 format, and you can't include TLS extensions. TLS extensions are not yet supported by OpenSSL, though.) [...] Thanks for the answer! :) Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
version 2 is used for Client Hello when version 3 was requested in client code
Hi,
well the (too long) subject explains it very well.
But here are the details.
I used the code from the book Network Security with OpenSSL to play
around with SSL.
The client code looks like:
SSL_CTX *setup_client_ctx(void)
{
SSL_CTX *ctx;
ctx = SSL_CTX_new(SSLv23_method());
if(SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
int_error(Error loading CA file and/or directory.);
if(SSL_CTX_set_default_verify_paths(ctx) != 1)
int_error(Error loading default CA file and/or directory.);
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
SSL_CTX_set_verify_depth(ctx, 4);
SSL_CTX_set_options(ctx, SSL_OP_ALL|SSL_OP_NO_SSLv2);
if(SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1)
int_error(Error setting cipher list (no valid ciphers));
return ctx;
}
You see I use SSLv23_method() and later SSL_CTX_set_options(ctx, SSL_OP_ALL
| SSL_OP_NO_SSLv2); to disable SSLv2 support.
Is it normal that the Client Hello message is SSLv2 and later TLS is used?
If I use SSLv3_method() everything works as expected.
I attached a ethereal capture file (see frame 4). Maybe the ethereal decoder
makes a mistake here or maybe it is normal behaviour.
Thanks,
Thomas
--
TheTom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF
sslv2.bin
Description: Binary data
pgpEM7nvEdv1Q.pgp
Description: PGP signature
Small bugs in v3 client hello parsing
Hi,
It seems that I've found two small bugs in OpenSSL (at least 0.9.6c
and the latest snapshot).
In ssl/s3_srvr.c function ssl3_get_client_hello, after the
last field (compression) has been parsed, there's a test:
/* TLS does not mind if there is extra stuff */
if (s-version == SSL3_VERSION)
{
if (p (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
goto f_err;
}
}
Here d points to the start of the message, p to the
current location, and n is the length of the frame.
There are actually two bugs: First, the test should of
course be p (d+n).
Second, if p (d+n) then we have read past the end of the packet
anyway so it is an error no matter which protocol version we have.
It seems that the memory buffer allocated is always large enough,
so this does not crash OpenSSL or anything like that, but it
causes OpenSSL to accept invalid hello packets.
Best regards,
Pasi
--
Pasi Eronen E-mail [EMAIL PROTECTED]
Nixu Oy Tel +358 50 5123499
Mäkelänkatu 91, 00610 Helsinki Fax +358 9 4781030
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Small bugs in v3 client hello parsing
It seems that I've found two small bugs in OpenSSL (at least 0.9.6c
and the latest snapshot).
In ssl/s3_srvr.c function ssl3_get_client_hello, after the
last field (compression) has been parsed, there's a test:
/* TLS does not mind if there is extra stuff */
if (s-version == SSL3_VERSION)
{
if (p (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
goto f_err;
}
}
Here d points to the start of the message, p to the
current location, and n is the length of the frame.
There are actually two bugs: First, the test should of
course be p (d+n).
Thanks. This will be fixed.
Second, if p (d+n) then we have read past the end of the packet
anyway [...]
A test is missing earlier in the code. This should fix all the problems:
Index: s3_srvr.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.49.2.13
diff -u -u -r1.49.2.13 s3_srvr.c
--- s3_srvr.c 2002/01/14 23:42:38 1.49.2.13
+++ s3_srvr.c 2002/04/13 22:17:58
@@ -711,7 +711,7 @@
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_NO_CIPHERS_SPECIFIED);
goto f_err;
}
- if ((i+p) (d+n))
+ if ((p+i) = (d+n))
{
/* not enough data */
al=SSL_AD_DECODE_ERROR;
@@ -768,6 +768,13 @@
/* compression */
i= *(p++);
+ if ((p+i) (d+n))
+ {
+ /* not enough data */
+ al=SSL_AD_DECODE_ERROR;
+ SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
+ goto f_err;
+ }
q=p;
for (j=0; ji; j++)
{
@@ -815,7 +822,7 @@
/* TLS does not mind if there is extra stuff */
if (s-version == SSL3_VERSION)
{
- if (p (d+n))
+ if (p (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
SSL_connect:failed in SSLv3 read server hello A
Does anyone know what could cause this error ? SSL_connect:failed in SSLv3 read server hello A This is the sequence of events: Received SOCKET_MESSAGE Of FD_CONNECT, Return Code = 0 'OpenSSL Callback : SSL_connect:before/connect initialization 'OpenSSL Callback : SSL_connect:SSLv3 write client hello A 'OpenSSL Callback : SSL_connect:failed in SSLv3 read server hello A connect()ed To:204.65.1.118 Port :2024 Received SOCKET_MESSAGE Of FD_WRITE Received SOCKET_MESSAGE Of FD_CLOSE thank you __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_connect:failed in SSLv3 read server hello A
Does anyone know what could cause this error ? SSL_connect:failed in SSLv3 read server hello A This is the sequence of events: Received SOCKET_MESSAGE Of FD_CONNECT, Return Code = 0 'OpenSSL Callback : SSL_connect:before/connect initialization 'OpenSSL Callback : SSL_connect:SSLv3 write client hello A 'OpenSSL Callback : SSL_connect:failed in SSLv3 read server hello A connect()ed To:204.65.1.118 Port :2024 Received SOCKET_MESSAGE Of FD_WRITE Received SOCKET_MESSAGE Of FD_CLOSE thank you __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL client side library hungs, when received SSLv3 Hello Request.
Yoshihiro Kawabe [EMAIL PROTECTED]: I found a small bug in `ssl/s3_both.c'. The ssl3_get_message function configured client side (! s-server) receives SSL3_MT_HELLO_REQUEST (SSLv3 Hello Request), then fall into eternal loop. `do-while loop` between 362 line and 388 line has no condition to escape from it when receives the SSL3_MT_HELLO_REQUEST message correctly. [...] Thanks for the report. Actually the problem has been found before, and is fixed in current snapshots available at URL:ftp://ftp.openssl.org/snapshot;type=d. You might want to test a 0.9.6 snapshot as we intend to release 0.9.6c (a bugfix release) soon. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Hello, your friend recommended openxxx to you
You have been invited to check out this adult site by one of your friends who visited us. our URL is http://www.openxxx.net/ enjoy, OpenXXX TEAM 2001 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Error in get client hello B
Try replacing SSL_clear() in the sequence with SSL_set_shutdown(ssl,SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN); SSL_shutdown(ssl); --Douglas Lee On Wed, 10 May 2000, Amit Chopra wrote: Hi, This is a more concise version of my earlier posts on the same matter. When my app comes up I create a pool of SSL structures (using SSL_new)that I intend to reuse for the connections as follows: SSL_clear(ssl); SSL_set_accept_state(ssl); SSL_set_fd(ssl,client); I do this before accepting every client connection. The problem appears when I follow below steps: 1. Open browser and establish connection with my app. I can browse others links over SSL as well.(fine) 2. Close browser. 3. Open browser again and establish connection with my app. My app fails saying "Error in get client hello B". This also happens when I cancel the certificate message that the broswers show. The problem happens with both IE(5) and Netscape(4.7). Using 0.9.4 SSL_read used to return with SSL_ERROR_WANT_READ. Using 0.9.5a SSL_read returns ERROR_SSL (Navigator 4.7). The problem disappers when I do a SSL_new for every connection. What might I be doing wrong here? I believe that the SSL state machine is not getting reset properly. What can I do to fix this? I want to avoid SSL_new everytime as I wish to avoid fragmentation. Would appreciate any help, Thanks, Amit. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Error in get client hello
Hi All,
I am facing a problem accepting SSL connections. I have a simple
multi-threaded SSL web server. For test purposes I have also written
a simple SSL client.
When I open an instance of IE (5.0) or Navigator(4.7),the browser
opens multiple connections with my server (one for each URI) and the
SSL transaction completes successfully. I can also browse other links
over SSL. But when I close the browser and open another instance of
it, the server gets caught in an infinite loop. It keeps getting
SSL_WANT_READ and on reading keeps returning 0 bytes read. The SSL
state dump shows 'SSL_accept: SSLv3 error in read client hello B'. For
connections that get negotiated successfully I see SSL_accept: SSLv3
read client hello A' and other then other correct handshake messages
follow.
But for the problem I cited it keeps saying 'SSL_WANT_READ' and
'SSL_accept: SSLv3 error in read client hello B' continuously in an
infinite loop.
My own test client is capable of spawning multiple threads,
each of which issues the same set of 'GET' requests and terminates the
connection. It seems to work fine. Only the browsers are giving me a
problem. And also my client works fine with sessionID caching ON or
OFF.
I am unable to understand the reason for this anomaly.
I am attaching some code below that does SSL_read. Kindly note that I
do an implicit SSL_accept.
I call DoSSLRead in response to a read event on the client socket. The
function that calls DoSSLRead
reads n number of bytes from the client and writes them to the web
server module.
// This function is called only when there is data to be received on
the socket.
// DoSSLRead reads data upto a max size of iSize and then returns.
// Returns -1 if failure.
//iSize is the size of data buffer (2K)
int DoSSLRead(SSL *pSSL, char * pData, int iSize, BOOL bMoreData)
{
int nBytesRead = 0; //number of bytes read
int iRet1, iRet2, iRet3;
bMoreData = FALSE; //Is there more data to be read ??
while (nBytesRead iSize)
{
iRet1 = SSL_read(pSSL, (pData + nBytesRead), (iSize - nBytesRead)) ;
if (iRet1 0)
{
nBytesRead += iRet1;
}
iRet2 = SSL_get_error(pSSL,iRet1);
switch (iRet2)
{
case SSL_ERROR_NONE:
iRet3 = SSL_pending(pSSL);
if (iRet3)
{
if (nBytesRead == iSize)
{
// There is more data pending but
// we have filled up the buffer completely.
// Indicate to the caller that more
// data is available and return.
bMoreData = TRUE;
return nBytesRead;
}
else
{
// There is more data pending and
// we still have not filled the buffer
// completely so call SSL_read again.
continue;
}
}
else
{
// There is no more data pending.
// Return the no. of bytes read.
return nBytesRead;
}
break;
case SSL_ERROR_WANT_READ:
// The data is available but SSL wants us to
// call SSL_read again. We should call SSL_read
// but only if we still haven't filled up
// the buffer.
if (SSL_in_init(pSSL))
{
if (nBytesRead iSize)
{
continue;
}
else
{
bMoreData = TRUE;
return nBytesRead;
}
}
else
{
return nBytesRead;
}
break;
case SSL_ERROR_WANT_WRITE:
break;
case SSL_ERROR_WANT_X509_LOOKUP:
break;
case SSL_ERROR_SYSCALL:
return -1; //terminate the connection
case SSL_ERROR_SSL:
return -1; //terminate the connection
case SSL_ERROR_ZERO_RETURN:
return -1; //terminate the connection
default:
DEBUGMSG("(DoSSLRead): UnHandled iRet2 = %d!!!\n", iRet2);
return -1; // for now terminate the connection
}//end of switch
}//end of while
return nBytesRead;
} //end of DoSSLRead
I would appreciate very much any help I can get.
Thanks,
Amit.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated Li
Re: Error in get client hello
Hi,
I want to add an observation that I have just made.
Previously I used to create a new SSL structure for every connection
and things worked fine.
Then I changed it so that I have a pool of SSL structures (to avoid
fragmentation)
and I reuse them by calling
SSL_clear(ssl);
SSL_set_accept_state(ssl);
SSL_set_fd(ssl,client);
This is when my negotiation with the broswers seem to fail and I get
'error in read client
hello B'. (Another question: What do 'A' and 'B' reperesnt?)
In the light of this observation, the read\write code seems to be
correct.
Does anyone know what I might be doing wrong when I reuse the SSL
structures ?
(I still use 0.9.4.)
Thanks,
Amit.
Amit Chopra wrote:
Hi All,
I am facing a problem accepting SSL connections. I have a simple
multi-threaded SSL web server. For test purposes I have also written
a simple SSL client.
When I open an instance of IE (5.0) or Navigator(4.7),the browser
opens multiple connections with my server (one for each URI) and the
SSL transaction completes successfully. I can also browse other links
over SSL. But when I close the browser and open another instance of
it, the server gets caught in an infinite loop. It keeps getting
SSL_WANT_READ and on reading keeps returning 0 bytes read. The SSL
state dump shows 'SSL_accept: SSLv3 error in read client hello B'. For
connections that get negotiated successfully I see SSL_accept: SSLv3
read client hello A' and other then other correct handshake messages
follow.
But for the problem I cited it keeps saying 'SSL_WANT_READ' and
'SSL_accept: SSLv3 error in read client hello B' continuously in an
infinite loop.
My own test client is capable of spawning multiple threads,
each of which issues the same set of 'GET' requests and terminates the
connection. It seems to work fine. Only the browsers are giving me a
problem. And also my client works fine with sessionID caching ON or
OFF.
I am unable to understand the reason for this anomaly.
I am attaching some code below that does SSL_read. Kindly note that I
do an implicit SSL_accept.
I call DoSSLRead in response to a read event on the client socket. The
function that calls DoSSLRead
reads n number of bytes from the client and writes them to the web
server module.
// This function is called only when there is data to be received on
the socket.
// DoSSLRead reads data upto a max size of iSize and then returns.
// Returns -1 if failure.
//iSize is the size of data buffer (2K)
int DoSSLRead(SSL *pSSL, char * pData, int iSize, BOOL bMoreData)
{
int nBytesRead = 0; //number of bytes read
int iRet1, iRet2, iRet3;
bMoreData = FALSE; //Is there more data to be read ??
while (nBytesRead iSize)
{
iRet1 = SSL_read(pSSL, (pData + nBytesRead), (iSize - nBytesRead)) ;
if (iRet1 0)
{
nBytesRead += iRet1;
}
iRet2 = SSL_get_error(pSSL,iRet1);
switch (iRet2)
{
case SSL_ERROR_NONE:
iRet3 = SSL_pending(pSSL);
if (iRet3)
{
if (nBytesRead == iSize)
{
// There is more data pending but
// we have filled up the buffer completely.
// Indicate to the caller that more
// data is available and return.
bMoreData = TRUE;
return nBytesRead;
}
else
{
// There is more data pending and
// we still have not filled the buffer
// completely so call SSL_read again.
continue;
}
}
else
{
// There is no more data pending.
// Return the no. of bytes read.
return nBytesRead;
}
break;
case SSL_ERROR_WANT_READ:
// The data is available but SSL wants us to
// call SSL_read again. We should call SSL_read
// but only if we still haven't filled up
// the buffer.
if (SSL_in_init(pSSL))
{
if (nBytesRead iSize)
{
continue;
}
else
{
bMoreData = TRUE;
return nBytesRead;
}
}
else
{
return nBytesRead;
}
break;
case SSL_ERROR_WANT_WRITE:
break;
case SSL_ERROR_WANT_X509_LOOKUP:
break;
case SSL_ERROR_SYSCALL
