For the record - this was committed on 16 January ("Omit initial status request
callback check"):
master:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d0b039d4a3a19b106cc2cb938125b86aca4974aa
OpenSSL_1_0_0-stable:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5df83
The implementation of SSL_set_SSL_CTX is fairly slim right now:
--- snip ---
SSL_CTX *SSL_set_SSL_CTX(SSL *ssl, SSL_CTX* ctx)
{
if (ssl->ctx == ctx)
return ssl->ctx;
#ifndef OPENSSL_NO_TLSEXT
if (ctx == NULL)
ctx = ssl->initial_ctx;
#endif
For the record - this fix has been committed in early August:
master:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5ae8d6bcbaff99423a2608559d738a3fcf7ed6dc
OpenSSL_1_0_0-stable:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=bcd092d70606e750d69a04a731c98fe16bb7668d
In t1_lib.c:ssl_scan_clienthello_tlsext (or
t1_lib.c:ssl_parse_clienthello_tlsext for versions up to 1.0.1), a
status_request extension in the ClientHello is currently parsed after
this check:
...
else if (type == TLSEXT_TYPE_status_request
&& s->ctx->tlsext_status_cb)
...
Checki
Is there a chance to get this fix into the next 1.0.x releases?
PEM_X509_INFO_read_bio() is used by mod_ssl (for the
SSLProxyMachineCertificateFile directive e.g.), and can cause
regressions with existing key files when people upgrade from 0.9.8 to
1.0.0 and later. See
https://issues.apache.org/bug
When PEM_X509_INFO_read_bio() was updated "to correctly assign private
keys" in 2006, a regression was introduced with processing RSA private
keys. Here is the diff:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=43c9825c2a2f2f552517d45d3f3e386a0fe37f2f
(or http://cvs.openssl.org/chng
[Second try. The attachment was left out by mistake.]
When using "-nameopt" with the x509/req/ca commands, OpenSSL will
currently "abort" the output if no sep_xxx option is provided. Examining
the certificate from https://rt.openssl.org with "openssl 509 -noout
-text -nameopt utf8" e.g. gives
Cer
When using "-nameopt" with the x509/req/ca commands, OpenSSL will
currently "abort" the output if no sep_xxx option is provided. Examining
the certificate from https://rt.openssl.org with "openssl 509 -noout
-text -nameopt utf8" e.g. gives
Certificate:
Data:
Version: 3 (0x2)
Se
>> else" could have a look at / comment on it (in particular someone
>> who's
Correcting myself (to keep English grammar straight):
s/who's/whose/, actually
> I'll look into this in more detail later, however on the face of it
> there's a conflict with draft-ietf-tls-rfc4366-bis-06.txt
> specifi
Here is a more "radical" attempt at solving this problem. In private
discussions with Peter Sylvester it became clear that the solution
I proposed last August would only superficially address the problem.
I'm therefore attaching a more comprehensive patch (against
OpenSSL_1_0_0_stable), which incl
When a TLS session is resumed, t1_lib.c:ssl_parse_clienthello_tlsext()
currently disregards an SNI extension which is potentially
included in the ClientHello, because the following if condition is false:
switch (servname_type)
{
case TLSEXT_NAMETYPE_host_name:
> To improve interoperability, I would recommend to not add any TLS
> extensions when speaking SSLv3 - as implemented by the attached patch
> (against HEAD, but also applies cleanly to openssl_0_9_8-stable).
Given that TLS extensions are enabled by default as of 0.9.8j,
the importance of this patc
> OpenSSL 0.9.8g SSLv3 only client (with tlsext support compiled in) is
> broken when communicating with some servers.
This is due to the fact that when compiled with enable-tlsext, OpenSSL
will currently also include TLS extensions in an SSLv3 ClientHello. In
the example shown, it's actually the
13 matches
Mail list logo
