Re: OpenSSL client DH group limits
On 11/06/2013 05:08 AM, Karthikeyan Bhargavan wrote: On the precise number of minimum bits, please note that IIS uses a static 768-bit Diffie Hellman prime, specifically Group 1 from IKEv2 (rfc5996, appendix B.1)/ I suspect a number of other servers may do the same; hence the numbers you see for NSS and GnuTLS. That's disappointing, esp. since RFC 5996 explicitly says: The strength supplied by group 1 may not be sufficient for typical uses and is here for historic reasons. Does anyone on this list have a contact in the IIS or SChannel team within Microsoft? I'd like to encourage them to change this. --dkg __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2771] [BUG] Openssl 1.0.1 times out when connecting to Outlook Exchange 2007
On Thu Mar 29 21:17:31 2012, steve wrote: > A temporary workaround for this is to apply these two patches to OpenSSL > 1.0.1: > > http://cvs.openssl.org/chngview?cn=22286 > http://cvs.openssl.org/chngview?cn=22306 > > And recompile OpenSSL with -DOPENSSL_NO_TLS1_2_CLIENT (e.g. supplied as > a command line option to config or Configure). I'm working on something > better. > A new experimental workaround has been added to the master branch. See: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=0467ea686244 This is less disruptive as it doesn't disable TLS 1.2 or chop the cipher list. 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: Need get() and clear() functions for chain_certs in 1.0.2-dev
On Wed, Nov 06, 2013, Rob Stradling wrote: > These 2 #defines exist for SSL_CTX->extra_certs: > SSL_CTX_add_extra_chain_cert > SSL_CTX_get_extra_chain_certs > SSL_CTX_clear_extra_chain_certs > > In 1.0.2-dev, the #defines such as SSL_CTX_add0_chain_cert allow me > to specify different chains for different certificate types, but > AFAICT there are no associated get() or clear() functions. > > I can't see a way to squeeze a standalone SSL_CTX_get_chain_certs > function into SSL_CTX_ctrl(). There's only 1 pointer argument > available, so I can't pass in an X509* (to indicate which cert I > want the chain for) and get back a STACK_OF(X509)* (the chain). > > One option would be to have another SSL_CTX_ctrl #define called > SSL_CTX_get_cert_type, which would accept an X509* and return the > index of that cert (i.e. SSL_CTX->CERT->pkeys[index]->x509), or -1 > if not found. That index could then be passed to > SSL_CTX_get_chain_certs in the larg argument. > However, since the SSL_PKEY_* #defines are private (in ssl_locl.h), > I'm unsure whether exposing these values in the public APIs would be > acceptable. > > The other option would be to write SSL_CTX_get_chain_certs() as a > proper function (instead of a SSL_CTX_ctrl #define), but I'm unsure > whether or not that would be better than the first option. > > Any preference? > The index for certificates could change in future so I'd rather not expose it in a public API. OpenSSL has the concept of a "current certificate" which could be used here. This refers to the last certificate set. So you'd have (for example) a way to retrieve extra chain certificates for the current certificate. For that to work properly you'd also have to have a way to set the current certtificate, without the risk of disturbing the existing structure. So perhaps something like: int SSL_set_current_cert(SSL *ssl, X509 *x); Which returns 1 and sets the current certificate to one containing 'x' if a match is found and returns 0 and does nothing if no match is found. Also with an SSL_CTX version. 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
Need get() and clear() functions for chain_certs in 1.0.2-dev
These 2 #defines exist for SSL_CTX->extra_certs: SSL_CTX_add_extra_chain_cert SSL_CTX_get_extra_chain_certs SSL_CTX_clear_extra_chain_certs In 1.0.2-dev, the #defines such as SSL_CTX_add0_chain_cert allow me to specify different chains for different certificate types, but AFAICT there are no associated get() or clear() functions. I can't see a way to squeeze a standalone SSL_CTX_get_chain_certs function into SSL_CTX_ctrl(). There's only 1 pointer argument available, so I can't pass in an X509* (to indicate which cert I want the chain for) and get back a STACK_OF(X509)* (the chain). One option would be to have another SSL_CTX_ctrl #define called SSL_CTX_get_cert_type, which would accept an X509* and return the index of that cert (i.e. SSL_CTX->CERT->pkeys[index]->x509), or -1 if not found. That index could then be passed to SSL_CTX_get_chain_certs in the larg argument. However, since the SSL_PKEY_* #defines are private (in ssl_locl.h), I'm unsure whether exposing these values in the public APIs would be acceptable. The other option would be to write SSL_CTX_get_chain_certs() as a proper function (instead of a SSL_CTX_ctrl #define), but I'm unsure whether or not that would be better than the first option. Any preference? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3162] enhancement request - PSK AES algorithms available in FIPS mode
Hi! I would like to request the following algorithms to be available in FIPS mode: TLS1_TXT_PSK_WITH_AES_128_CBC_SHA TLS1_TXT_PSK_WITH_AES_256_CBC_SHA Please see the "DTLS PSK in FIPS mode" discussion on then openssl-users list. Attached is a patch for s3_lib.c that makes the said algorithms available in FIPS mode. Best regards, Fredrik Jansson s3_lib.patch Description: Binary data
[openssl.org #3161] [PATCH 2/2] Avoid deprecated defined(@array) in mkerr.pl
Without these changes, running util/mkerr.pl on modern perl (5.18.1)
produces the following deprecation warnings:
defined(@array) is deprecated at util/mkerr.pl line 792.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at util/mkerr.pl line 800.
(Maybe you should just omit the defined()?)
---
util/mkerr.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/mkerr.pl b/util/mkerr.pl
index 49a52a7..b726282 100644
--- a/util/mkerr.pl
+++ b/util/mkerr.pl
@@ -789,7 +789,7 @@ foreach (keys %rcodes) {
push (@runref, $_) unless exists $urcodes{$_};
}
-if($debug && defined(@funref) ) {
+if($debug && @funref ) {
print STDERR "The following function codes were not referenced:\n";
foreach(sort @funref)
{
@@ -797,7 +797,7 @@ if($debug && defined(@funref) ) {
}
}
-if($debug && defined(@runref) ) {
+if($debug && @runref ) {
print STDERR "The following reason codes were not referenced:\n";
foreach(sort @runref)
{
--
1.8.4.rc3
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3160] [PATCH 1/2] disambiguate SSL_R_NO_PEM_EXTENSIONS from SSL_R_INVALID_SERVERINFO_DATA
Somehow, both SSL_R_NO_PEM_EXTENSIONS and SSL_R_INVALID_SERVERINFO_DATA were assigned reason code 389. This patch uses the next available number (393) for SSL_R_NO_PEM_EXTENSIONS to disambiguate the two reason codes. --- ssl/ssl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ssl/ssl.h b/ssl/ssl.h index 472e070..31edf7f 100644 --- a/ssl/ssl.h +++ b/ssl/ssl.h @@ -2912,7 +2912,7 @@ void ERR_load_SSL_strings(void); #define SSL_R_NO_COMPRESSION_SPECIFIED 187 #define SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER 330 #define SSL_R_NO_METHOD_SPECIFIED 188 -#define SSL_R_NO_PEM_EXTENSIONS 389 +#define SSL_R_NO_PEM_EXTENSIONS 393 #define SSL_R_NO_PRIVATEKEY 189 #define SSL_R_NO_PRIVATE_KEY_ASSIGNED 190 #define SSL_R_NO_PROTOCOLS_AVAILABLE191 -- 1.8.4.rc3 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL client DH group limits
We noticed the same thing and would also recommend that the openssl client
reject small DH groups.
This would complement the strong validity checks that openssl already by e.g.
checking primality and rejecting invalid public keys.
On the precise number of minimum bits, please note that IIS uses a static
768-bit Diffie Hellman prime, specifically Group 1 from IKEv2 (rfc5996,
appendix B.1)/
I suspect a number of other servers may do the same; hence the numbers you see
for NSS and GnuTLS.
Best,
Karthik
On Nov 6, 2013, at 5:44 AM, Daniel Kahn Gillmor wrote:
> I noticed recently that OpenSSL as a client is happy to connect to a
> server that offers a trivially-crackable DH group.
>
> You can try it out at https://demo.cmrg.net/
>
> Other modern TLS implementations will refuse to connect to this server
> because the DHE group is only 16 bits. OpenSSL happily connects and
> does not inform the user that their expected message authenticity and
> confidentiality and integrity guarantees are not being met. I consider
> this a security failure in the key exchange, just as i would consider it
> a failure for OpenSSL to silently accept a known-broken cipher or MAC
> from its peer.
>
> I'd like to propose that the OpenSSL client implementation reject
> connections to peers that offer DH groups < 1024 bits, rather than
> failing open. The attached patch should have this effect.
>
> Other free software TLS implementations already have limits on DH group
> size below which the TLS client refuses DHE connections:
>
> * GnuTLS ~760 bits
> * polarssl 512 bits
> * NSS 512 bits
>
> Despite being stronger than OpenSSL currently is here, most of these
> limits are still too weak to consider even for legacy use, according to
> recent recommendations such as:
>
> http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report
>
> P.34 there indicates that 1024 bits for DLP is the limit of
> acceptability for "legacy" systems, and that for "near term" resistance,
> 3072 bits is recommended.
>
> Thoughts?
>
>--dkg
>
> Here's the patch, which i'll file on RT shortly:
>
>
> Author: Daniel Kahn Gillmor
> Date: Tue Nov 5 19:37:22 2013 -0500
>
>require DH group of 1024 bits
>
>Reject connections to TLS servers that select DH key exchange but
>offer a weak DH group.
>
> diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
> index bf1ef47..ef638c4 100644
> --- a/ssl/s3_clnt.c
> +++ b/ssl/s3_clnt.c
> @@ -3481,6 +3481,12 @@ int ssl3_check_cert_and_algorithm(SSL *s)
>
> SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_MISSING_DH_RSA_CERT);
> goto f_err;
> }
> +else if ((alg_k & (SSL_kEDH|SSL_kDHr|SSL_kDHd)) &&
> + (dh == NULL || DH_size(dh)*8 < 1024))
> + {
> + SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_WEAK_DH_GROUP);
> + goto f_err;
> + }
> #ifndef OPENSSL_NO_DSA
> else if ((alg_k & SSL_kDHd) && !SSL_USE_SIGALGS(s) &&
> !has_bits(i,EVP_PK_DH|EVP_PKS_DSA))
> diff --git a/ssl/ssl.h b/ssl/ssl.h
> index 472e070..3ea316c 100644
> --- a/ssl/ssl.h
> +++ b/ssl/ssl.h
> @@ -3062,6 +3062,7 @@ void ERR_load_SSL_strings(void);
> #define SSL_R_UNSUPPORTED_SSL_VERSION 259
> #define SSL_R_UNSUPPORTED_STATUS_TYPE 329
> #define SSL_R_USE_SRTP_NOT_NEGOTIATED 369
> +#define SSL_R_WEAK_DH_GROUP 371
> #define SSL_R_WRITE_BIO_NOT_SET260
> #define SSL_R_WRONG_CERTIFICATE_TYPE 383
> #define SSL_R_WRONG_CIPHER_RETURNED261
> diff --git a/ssl/ssl_err.c b/ssl/ssl_err.c
> index 9889a27..a97b4b5 100644
> --- a/ssl/ssl_err.c
> +++ b/ssl/ssl_err.c
> @@ -612,6 +612,7 @@ static ERR_STRING_DATA SSL_str_reasons[]=
> {ERR_REASON(SSL_R_UNSUPPORTED_SSL_VERSION),"unsupported ssl version"},
> {ERR_REASON(SSL_R_UNSUPPORTED_STATUS_TYPE),"unsupported status type"},
> {ERR_REASON(SSL_R_USE_SRTP_NOT_NEGOTIATED),"use srtp not negotiated"},
> +{ERR_REASON(SSL_R_WEAK_DH_GROUP) ,"weak dh group"},
> {ERR_REASON(SSL_R_WRITE_BIO_NOT_SET) ,"write bio not set"},
> {ERR_REASON(SSL_R_WRONG_CERTIFICATE_TYPE),"wrong certificate type"},
> {ERR_REASON(SSL_R_WRONG_CIPHER_RETURNED) ,"wrong cipher returned"},
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majord...@openssl.org
smime.p7s
Description: S/MIME cryptographic signature
Re: [openssl.org #3152] AutoReply: Segfault in d1_pkt.c in FIPS mode
Hi!
I would like to close this since it's not a bug.
Best regards,
Fredrik Jansson
On Mon, Oct 28, 2013 at 9:33 AM, The default queue via RT
wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Segfault in d1_pkt.c in FIPS mode",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [openssl.org #3152].
>
> Please include the string:
>
> [openssl.org #3152]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> r...@openssl.org
>
> -
> OpenSSL 1.0.1e
>
> In the function dtls1_get_record the pointer p is initialized to NULL at
> function entry. Later the pointer may be initialized inside an if
> statement. The pointer is later dereferenced, w/o null check, resulting in
> a segfault.
>
> In our product this only happens when OpenSSL is in FIPS mode.
>
> I have supplied a simple patch that solves the problem on my test machines.
>
> Best regards,
> Fredrik Jansson
>
> "Pseudo code"
>
> unsigned char *p = NULL;
>
> ...
>
> if ( (s->rstate != SSL_ST_READ_BODY) ||
>
> (s->packet_length < DTLS1_RT_HEADER_LENGTH))
>
> {
>
> ...
>
> p = s->packet;
>
> ...
>
> }
>
> ...
>
> if (!(s->d1->listen && rr->type == SSL3_RT_HANDSHAKE &&
>
> *p == SSL3_MT_CLIENT_HELLO) &&
>
> !dtls1_record_replay_check(s, bitmap)) { ... }
>
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
