[openssl-dev] [openssl.org #3757] OpenSSL decodes malformed base64 encoded inputs
Hi!
Looking at the CVE-2015-0292 fix:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9febee0272
the added (eof > v) check seems somewhat suspicious. While it prevents
integer underflow that causes out of bounds memcpy(), it still allows
some messing with output via proper number of trailing '=' signs. The
code was apparently written under assumption that eof is in the rage of
0 - 2, which are the only valid counts of '=' in proper base64 encoded
data.
One possible issue is that extraneous '=' will lead to decoded data to
contain extraneous trailing '\0's:
$ echo T3BlblNTTE9wZW5TU0wK`python -c 'print "="*40'` | openssl enc -d -base64
| hexdump -c
000 O p e n S S L O p e n S S L \n \0
010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
02b
However, it can also cause output to be truncated:
$ echo T3BlblNTTE9wZW5TU0wK`python -c 'print "="*44'` | openssl enc -d -base64
| hexdump -c
000 O p e n
004
Decoding should probably reject such malformed inputs. If the
expectation is to tolerate malformed inputs with extraneous trailing
'='s, it can do something like:
if (eof % 4 == 3) { /* error */ }
ret+=(v - ((eof/4)*3) - (eof%4))
This should ensure proper number of trailing '\0's are ignored.
However, there are other code paths that would need amending, as eof
gets reset to the expected 0-2 range in some cases. However, code will
also need to check that no '=' appears in the middle of the input.
Examples of other malformed inputs that should be rejected:
$ echo YQ==YQ==YQ== | openssl enc -d -base64 | hexdump -c
000 a \0 \0 a \0 \0 a
007
$ echo A=== | openssl enc -d -base64 | hexdump -c
000 \0
001
--
Tomas Hoger
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Poodle Vulnerable
On Thu, 29 Jan 2015 06:33:13 + Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > For poodle vulnerability we have upgraded the openssl to 0.9.8zc > version. But still result shows as vulnerable. (downloaded poodle.sh > script from the link https://access.redhat.com/articles/1232123 to > verify) The script checks if a target server has SSL 3.0 enabled, i.e. the PO part of POODLE. OpenSSL 0.9.8zc does not address that, it adds a feature (TLS_FALLBACK_SCSV) to help mitigate/block the DLE part. The script does not attempt to check if the server implements this fallback protection. -- Tomas Hoger ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [PATCH] Add API to set minimum and maximum protocol version.
On Thu, 4 Dec 2014 10:57:11 +0100 Kurt Roeckx wrote: > > It seems *TLS*_VERSION constants are meant to be used to set > > minimum / maximum. A drawback of such approach is that > > applications need to be recompiled and/or modified when OpenSSL is > > updated with support for newer protocol version, if use of the new > > version is to be controlled via this API. > > So if I understand you right, say that we make a release that > support up to TLS 1.2 and your application is compiled against > that. That would mean it will only know how to set the minimum > and maximum to TLS 1.2. If I then add support for TLS 1.3 there > would be no way to say that TLS 1.3 should be the minimum without > adding support for that in the application? Right. Look at it with your Debian openssl packages maintainer hat on - how many packages need to be modified to support 1.3? > > SSLProtocolMin "TLSv1.0" > > > > instead of > > > > SSLProtocol all -SSLv2 -SSLv3 > > > > Or maybe have a way to control protocol versions via cipher suite > > string. Similar to what GnuTLS does with its priority string, which > > can set ciphers, protocol versions, etc. > > I was thinking about that too before. We already have SECLEVEL in > there now (in 1.0.2). What is the SECLEVEL you refer to? I had a quick look at SSL_CONF API pointed out by Stephen. I see it can do what I asked for (not the min/max way, but the httpd-like way). -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Add API to set minimum and maximum protocol version.
On Wed, 3 Dec 2014 22:55:06 +0100 Kurt Roeckx wrote: > This is an initial patch to support being able to set the minimum > and maximum protocol version. The patch is currently untested, > that will happen as I rewrite other things. But I'm looking for > feedback. It seems *TLS*_VERSION constants are meant to be used to set minimum / maximum. A drawback of such approach is that applications need to be recompiled and/or modified when OpenSSL is updated with support for newer protocol version, if use of the new version is to be controlled via this API. We've seen such issues when OpenSSL was updated from 1.0.0 to 1.0.1 in Red Hat Enterprise Linux. Some users needed to disable TLS 1.2 in mod_ssl, but that required httpd changes. Maybe applications may benefit from an API where they can pass string set by the end user and let OpenSSL parse version number from that. If mod_ssl had configuration directives as SSLProtocolMin and SSLProtocolMax, it could e.g. use the following while used with OpenSSL 1.0.0: SSLProtocolMin "TLSv1.0" instead of SSLProtocol all -SSLv2 -SSLv3 If TLS 1.2 is undesired after rebase to OpenSSL 1.0.1, this can be added: SSLProtocolMax "TLSv1.1" The httpd could be able to treat SSLProtocolMin/Max strings as opaque, just like SSLCipherSuite. Or maybe have a way to control protocol versions via cipher suite string. Similar to what GnuTLS does with its priority string, which can set ciphers, protocol versions, etc. http://gnutls.org/manual/html_node/Priority-Strings.html#Priority-Strings There are applications using OpenSSL that allow their users to control cipher string, but offer no way to set protocol versions. Just 2c ideas about the API, I've not reviewed the patch. -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Possible missing CVE inside the Release Notes/Security Advisory
On Thu, 7 Aug 2014 15:07:44 +0200 Alexander Bergmann wrote: > Is CVE-2014-3511 "TLS protocol downgrade attack" also affecting the > 0.9.8/1.0.0 branches? The issue is described as downgrade *to* TLS 1.0, which is the highest version supported by OpenSSL before 1.0.1. -- Tomas Hoger / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3234] [bug] openssl defaults to using tls compression
On Mon, 13 Jan 2014 17:26:23 +0100 Jeff Hodges via RT wrote: > According to [1], TLS compression is still the default configuration > of OpenSSL. This opens OpenSSL and all dependent tools (python, ruby, > etc.) to the CRIME attack. There was some discussion on this topic on openssl-dev before, that has some related ideas noted (e.g. what to do with SSL_OP_NO_COMPRESSION option): http://www.mail-archive.com/openssl-dev@openssl.org/msg31576.html -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3199] [BUG] Crash in DTLS renegotiation after packet loss
Fixed in 1.0.1f and 1.0.0l: http://www.openssl.org/news/vulnerabilities.html#2013-6450 th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3200] Crash in OpenSSL 1.0.1e w/TLS 1.2 (under load)
On Wed, 18 Dec 2013 23:42:08 +0100 Stephen Henson via RT wrote: > Many thanks for that info. I think I've traced the cause of the thing > now with that clue. It might have security implications (DoS only > though) so I'll keep any further details off the public mailing lists. This is now covered by CVE-2013-6449 and fixed in 1.0.1f: http://www.openssl.org/news/vulnerabilities.html#2013-6449 I assume this RT can be closed now. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and CRIME
On Thu, 18 Oct 2012 23:55:41 +0200 Andrey Kulikov wrote: > > OpenSSL enables zlib by default. > > Could you please advice for what version and platform this is true? > > openssl-1.0.1c for linux-elf > has no-zlib configured by default. Sorry, I asked the wrong way. OpenSSL, when compiled with zlib support, enables deflate (id 1) compression by default. I was wondering if this should stay as is or should change to disabled by default even when zlib support is compiled in (i.e. compression will only get used when explicitly enabled by an application using the library). The change would render SSL_OP_NO_COMPRESSION meaningless and possibly want a new option for doing the opposite. -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL and CRIME
Hi! Are there any plans to apply any changes to OpenSSL related to the recent CRIME attack? Unlike other libraries (e.g. GnuTLS or NSS), OpenSSL enables zlib by default. Is there a plan to change the default in response to the published attack? I'm aware of the existing SSL_OP_NO_COMPRESSION option as a workaround. Thank you! -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2826] OpenSSL Buffer Overflow Vulnerability Notification
On Thu, 31 May 2012 20:41:21 +0200 (CEST) David Anthony via RT wrote:
> There has been a new security vulnerability we have reported over at
> Bugtraq (http://seclists.org/bugtraq/2012/May/155) and we feel that it
> should also be reported to the OpenSSL dev team. If there are any
> questions regarding the issue, please feel free to give us (Myself
> and Vincent Buccigrossi) an email at this address to discuss further.
This should be a problem with apps' password_callback, that passes
incorrect buffer size to UI functions. The easy way to reproduce is
with genrsa, where both stack-based (first pass phrase prompt) and
heap-based (verify pass phrase prompt) overflows can be reproduced.
Attached patch for 1.0.1c makes password_callback use correct buffer
size.
--
Tomas Hoger
diff -pruN openssl-1.0.1c.orig/apps/apps.c openssl-1.0.1c/apps/apps.c
--- openssl-1.0.1c.orig/apps/apps.c 2012-02-12 00:38:49.0 +0100
+++ openssl-1.0.1c/apps/apps.c 2012-06-14 15:32:09.634491031 +0200
@@ -586,12 +586,12 @@ int password_callback(char *buf, int buf
if (ok >= 0)
ok = UI_add_input_string(ui,prompt,ui_flags,buf,
-PW_MIN_LENGTH,BUFSIZ-1);
+PW_MIN_LENGTH,bufsiz-1);
if (ok >= 0 && verify)
{
buff = (char *)OPENSSL_malloc(bufsiz);
ok = UI_add_verify_string(ui,prompt,ui_flags,buff,
-PW_MIN_LENGTH,BUFSIZ-1, buf);
+PW_MIN_LENGTH,bufsiz-1, buf);
}
if (ok >= 0)
do
Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
On Sun, 19 Feb 2012 18:44:24 -0700 Guan Jun He wrote: > >> > It seems you're trying to address more than just CVE-2011-1473 > >> > via this patch, which results in a fairly large patch. Why do > >> > you need to track client IP at all? This issue is about > >> > client's ability to do unlimited number of renegotiations within > >> > single connection. To limit that (either to a maximum total, or > >> > rate limiting), you should not really need to care about > >> > client's IP. > >> > >> If do not care about client's IP, then the rate limiting is > >> aimless, that means all legitimate ssl requests will be blocked, > >> and cause another 'DoS'. > > > > The issue is about renegotiations. If the fix allows all initial > > handshakes and only penalizes all connections that do many > > rehanshakes, there's no DoS as you suggest and should be sufficient > > to address CVE-2011-1473. > > Actually,the patch is based on the ssl protocol's "client hello", > initial handshakes and rehanshakes both use this, so the patch > does not differ them, find one "client hello" just increase the > counter. So, it can fix both 'initial handshakes DoS' and > 'rehanshakes DoS'. Yes, I understand what you're trying to do with your patch. I was only suggesting that extra checks you do on top of what CVE-2011-1473 is about result it in a bigger (read: apparently less likely to be accepted) patch. But again, I can't speak for openssl team, just offering my 2c. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
On Wed, 11 Jan 2012 21:04:33 -0700 Guan Jun He wrote: > > It seems you're trying to address more than just CVE-2011-1473 via > > this patch, which results in a fairly large patch. Why do you need > > to track client IP at all? This issue is about client's ability to > > do unlimited number of renegotiations within single connection. To > > limit that (either to a maximum total, or rate limiting), you > > should not really need to care about client's IP. > > If do not care about client's IP, then the rate limiting is aimless, > that means all legitimate ssl requests will be blocked, and cause > another 'DoS'. The issue is about renegotiations. If the fix allows all initial handshakes and only penalizes all connections that do many rehanshakes, there's no DoS as you suggest and should be sufficient to address CVE-2011-1473. > > Please correct me if I'm wrong, but if I remember correctly, > > s_server only handles single SSL connection at the time. The next > > connection is only accepted (SSL handshake) when the existing > > connection is closed. I'd expect the above test to open 1 SSL > > connection to s_server, with bunch of other s_client connections > > being established, but waiting for SSL handshake. This does not > > sound like a valid test case. > > Seems like you are right! > Do you have any good methord to test this? You want something that does not block rehandshakes. s_server should be sufficient if you're only after limiting renegotiations within one connection. httpd blocks client-initiated renegotiation for a while. stunnel may work as a good target. You probably want to look at something using custom BIO too. -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
Hi Guanjun! On Sun, 11 Dec 2011 20:35:02 -0700 Guan Jun He wrote: > I have just produced a patch against the upstream HEAD version, to > seek a way to fight against DoS attack in openssl itself, the logic > is simple, get client's ip address in BIO layer, and send this info > to upper SSL layer; In SSL layer, according to the client ip and > control policy to do control. And I have just finished the > enhancement to use rb-tree as the main struct, the patch is > attached,and have took a simple test from 2 machines. It seems you're trying to address more than just CVE-2011-1473 via this patch, which results in a fairly large patch. Why do you need to track client IP at all? This issue is about client's ability to do unlimited number of renegotiations within single connection. To limit that (either to a maximum total, or rate limiting), you should not really need to care about client's IP. You also seem to store IP as 32bit value, which does not sound like it should work correctly for IPv6. Your IP tracking probably helps limit total number of handshakes (initial or renegotiation) from one IP over all connections. It may be easier to limit handshakes in one connection and enforce connection limit (max concurrent connections or connection rate) elsewhere, where it can be done easily and where it's usually done - in firewall. Your mails suggest that you're actually testing it by doing only initial handshake over multiple connections, rather than using re-handshakes within single connection. On Mon, 19 Dec 2011 02:11:23 -0700 Guan Jun He wrote: > I have just tested and updated the patch,it works ok,and with a > little performance loss(<1%). The script used looks like this: > > for o3 in `seq 1 254`; do > for o4 in `seq 1 254`; do > host=127.0.$o3.$o4 > openssl s_client -ssl3 -connect $host:4433 & > done > sleep 1 > done > > the server side is like this: openssl s_server Please correct me if I'm wrong, but if I remember correctly, s_server only handles single SSL connection at the time. The next connection is only accepted (SSL handshake) when the existing connection is closed. I'd expect the above test to open 1 SSL connection to s_server, with bunch of other s_client connections being established, but waiting for SSL handshake. This does not sound like a valid test case. HTH -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Wed, 4 Jan 2012 21:04:06 +0100 (CET) OpenSSL wrote: > SGC Restart DoS Attack (CVE-2011-4619) > == > > Support for handshake restarts for server gated cryptograpy (SGC) can > be used in a denial-of-service attack. This issue seems to fall into the same category as CVE-2011-1473 that has been asked about on openssl lists couple of times and does not seem to have got feedback from openssl team. http://thread.gmane.org/gmane.comp.encryption.openssl.user/43645/focus=43699 http://thread.gmane.org/gmane.comp.encryption.openssl.user/43706 http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19839 There was a request for guidance on how to best work around this in applications, whether callback approach is the recommended one: http://thread.gmane.org/gmane.comp.encryption.openssl.user/43304 Also some efforts to propose a fix: http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19872 Can anyone from openssl team provide a statement on this issue and clarify if there are any changes planned to be made in openssl (be it a change that throttles or limits renegotiations, or makes it easier for applications to do so), comment on what kind of openssl fix may be acceptable, or recommend a way to best handle this in applications if no openssl fix is planned? Thank you! -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Client Initiated Renegotiation after 0.9.8l
On Wed, 13 Apr 2011 18:42:45 -0400 Chris Hill wrote: > It seems like in releases after OpenSSL 0.9.8l (the ones that > contained the fix for cve 2009-3555), client initiated "secure/safe" > renegotiationw was never re-enabled by default, judging by how Apache > behaves. See: http://groups.google.com/group/mailing.openssl.dev/browse_thread/thread/6d018d33a0f4a7af/f2542e431532cad9 "... current mod_ssl always rejects client initiated renegotiation." You should see the difference if you retest with s_server. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Blacklisting certificates by serial-id and parent certificate
On Wed, 30 Mar 2011 00:45:42 +0200 Hannes Frederic Sowa wrote: > Because of recent events with Comodo I tried to globally blacklist > their stolen certificates on my system. As they only published the > serial numbers of the fraud certificates [1] The certificates are public too, you can get them from e.g. mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=642395 HTH th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SSL renegotiation failing even after enabling SSLInsecureRenegotiation directive.
On Mon, 6 Sep 2010 15:12:34 +0530 gaurav jha wrote: > The problem is my handshake goes through successfully, but in > application data stage client initiates the renegotiation upon which > i get thrown an error and the connection terminates. I did enable > SSLInsecureRenegotiation directive, but the error persists. SSLInsecureRenegotiation setting and RFC 5746 support on the client side do not matter in your case, current mod_ssl always rejects client initiated renegotiation. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2174] SSL_CTX_new SSL_OP_LEGACY_SERVER_CONNECT may clear previously set option
Hi! SSL_CTX_new currently contains: /* Setup RFC4507 ticket keys */ if ((RAND_pseudo_bytes(ret->tlsext_tick_key_name, 16) <= 0) || (RAND_bytes(ret->tlsext_tick_hmac_key, 16) <= 0) || (RAND_bytes(ret->tlsext_tick_aes_key, 16) <= 0)) ret->options |= SSL_OP_NO_TICKET; followed by: /* Default is to connect to non-RI servers. When RI is more widely * deployed might change this. */ ret->options = SSL_OP_LEGACY_SERVER_CONNECT; So even if SSL_OP_NO_TICKET is set, it should be unset again due to a SSL_OP_LEGACY_SERVER_CONNECT default. Will SSL_OP_LEGACY_SERVER_CONNECT remain part of SSL_OP_ALL once SSL_OP_LEGACY_SERVER_CONNECT is no longer default? -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2102] 1.0.0 incompatible with openfire servers
Hi Eren! On Mon, 16 Nov 2009 01:19:11 +0200 Eren Türkay wrote: > > The only way to get established ssl handshake openssl s_client is > > to use the -ssl3 option. In some cases such as: > > This is the same situation in 0.9.8-stable branch, too. The only way > to connect to the server is -ssl3 option. With -tls1, openssl cannot > get hello message from the server. Problem reported by Tomas should be unrelated to the recent renegotiation fixes as it's reproducible with 0.9.8k too (when using -tls1 argument for s_client) and -no_ticket was reported to help. > However, when I pass -tls1 option, localhost just works fine.. Also, > renegotiation is done. If I'm not wrong, 0.9.8-stable branch contains > TLS extension for renegotiation issue. ... > I think, there are some problems with s_client, rather than > implementation. As seen from this, -tls1 option works fine with newer > openssl on both client and server. The difference between 1.0.0 and 0.9.8 should be caused by what I mentioned here (different client hello versions): http://marc.info/?l=openssl-dev&m=125803022028046&w=2 The same difference between versions is likely to be the reason why the openfire issue was only reported for 1.0.0. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Renegotiation behavior in 0.9.8l
Hi Steve! On Wed, 11 Nov 2009 16:08:36 +0100 "Dr. Stephen Henson" wrote: > On Wed, Nov 11, 2009, Tomas Hoger wrote: > > > This is unclear, they are banned in 0.9.8-stable, but 1.0.0beta4 > > seems to allow all, even those without an extension. > > Sorry about that, the port I did to 1.0.0 was broken and missed out > several changes, should be fixed by tomorrows snapshot. Thanks for clarification. I re-tested with current 1.0.0-stable CVS and the behavior is now similar to 0.9.8-stable. Both versions also enforce client extension checks (4.1 of reneg RFC). Interesting case is when client is using SSLv23_client_method (as e.g. s_client does by default) is trying to talk to TLSv1 server. In 0.9.8, SSLv2 Client Hello is sent indicating TLSv1 as the highest supported protocol version. Server Hello is TLSv1 and does not contain extension, hence client fails even when talking to new server. I don't see this behavior with 1.0.0-stable's s_client thanks to ssl23_no_ssl2_ciphers check. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: problem with creating cert with openssl x509
On Wed, 11 Nov 2009 09:01:41 -0800 (PST) Al wrote: > is the date format correct then? the x509 doesnt seem to give me the > exact format for datesetting and i used YYMMDDHHMMSSZ. I tried other > formats but all no good. How did you set yours? man 1 x509 -startdate prints out the start date of the certificate, that is the notBefore date. man 1 ca -startdate date this allows the start date to be explicitly set. The format of the date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure). th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Test of disabled renegotiation in 0.9.8l
On Wed, 11 Nov 2009 13:00:09 +0100 "Boyle Owen" wrote: > This stays like this until I kill the session. Is this the intended > behaviour? I thought it was supposed to drop the connection? Probably not intended, at least behavior of current 0.9.8-stable CVS is different now. See my mail with quite similar question: http://marc.info/?l=openssl-dev&m=125792743829558&w=2 Not an official answer, but hope it helps a bit. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Renegotiation behavior in 0.9.8l
Hi! I did some more testing with 1.0.0beta4 and current 0.9.8-stable CVS branch to hopefully answer some of my questions. On Mon, 9 Nov 2009 10:00:01 +0100 Tomas Hoger wrote: > Following cn18794 changed that however. After receiving Client Hello, > server sends no reply to the client, calls SSL_clear and read-block in > an attempt to read Hello. So both client and server are trying to > read from the connection and neither detects the connection is not > usable any more. ... > - Is that intended behavior? Is server not sending alert on purpose? 0.9.8-stable does send an alert and tears down connection immediately. So the behavior in 0.9.8l was not really intended. > - Is SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION going to stay or > disappear with the addition of reneg extension? My bad, cn18804 answers that already: Unfortunately, SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION turns out to be a bad idea. It has been replaced by SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which can be set with SSL_CTX_set_options(). > - Will all renegotiations remain banned by default even in versions > with reneg extension implemented? This is unclear, they are banned in 0.9.8-stable, but 1.0.0beta4 seems to allow all, even those without an extension. > - In 0.9.8l, when server calls SSL_renegotiate / SSL_do_handshake, no > Hello Request is sent. Will this behavior remain the same in future > versions? 0.9.8-stable does send Hello Request. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Renegotiation behavior in 0.9.8l
Hi! Can anyone please clarify what is the intended renegotiation behavior in openssl 0.9.8l and later? Judging from the cn18790, original intention was for the server to generate fatal alert and break connection when renegotiation Client Hello is received. Following cn18794 changed that however. After receiving Client Hello, server sends no reply to the client, calls SSL_clear and read-block in an attempt to read Hello. So both client and server are trying to read from the connection and neither detects the connection is not usable any more. Note: If you're curious, the same occurs when server sets SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS flag when using 0.9.8k. Additionally, cn18804 completely reverts cn18790. So my questions are: - Is that intended behavior? Is server not sending alert on purpose? - Is SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION going to stay or disappear with the addition of reneg extension? - Will all renegotiations remain banned by default even in versions with reneg extension implemented? - In 0.9.8l, when server calls SSL_renegotiate / SSL_do_handshake, no Hello Request is sent. Will this behavior remain the same in future versions? Thanks for clarifications! th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
