Re: [openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID
Hi, Am 11.05.2015 um 13:48 schrieb Hubert Kario via RT: On Saturday 09 May 2015 18:22:52 Benny Baumann via RT wrote: Hi, as the normal specification of cipher strings can be somewhat clumsy to use from time to time it would be nice if one could use the raw ID of a cipher (with all the usual operators): ALL:!0x00c012 Allow everything except TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA HIGH:-AES:+0x00c030 Allow all HIGH secure ciphers except AES, but explicitly include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + operator doesn't add a cipher, it moves matching ones to end of list This explains why GnuTLS and OpenSSL prodeuce vastly different results here ;-) Good to know. Wouldn't have been a better choice than? ;-) AES256:-0xc030:+AES+GCM Allow AES256, but (soft-)exclude TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, if it's not in the AESGCM ciphers list. again, you're describing what would happen with AES256:-0xc030:AES+GCM Additionally it would be awesome if one could simply use the names as they appear in the RFCs ;-) that would make the strings longer, wouldn't it? :) Yes, but much more easily to compare with the RFCs which ciphers are to be selected. It's not as if you are writing such strings all the time. master has support for printing the IETF/IANA names, see -stdname options to ciphers subcommand... Why would -stdname include -verbose? Does this work in reverse yet? Regards, BenBE. smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID
Hi, as the normal specification of cipher strings can be somewhat clumsy to use from time to time it would be nice if one could use the raw ID of a cipher (with all the usual operators): ALL:!0x00c012 Allow everything except TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA HIGH:-AES:+0x00c030 Allow all HIGH secure ciphers except AES, but explicitly include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 AES256:-0xc030:+AES+GCM Allow AES256, but (soft-)exclude TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, if it's not in the AESGCM ciphers list. Additionally it would be awesome if one could simply use the names as they appear in the RFCs ;-) Regards, BenBE. smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Fwd: Problem with encoding a CRL's signing algorithm
Hi,
I think there is somewhat strange behaviour in OpenSSL that causes
interesting bugs to happen when trying to encode CRLs based on deltas.
More information about the issue (causing a segfault under certain
conditions) is in the attached mail by Felix who discovered it.
Regards,
BenBE.
---BeginMessage---
Hi,
I am trying to encode deltas between CRLs directly in ASN1 (DER), which
works quite fine. Thereby I stumbled across a problem with encoding
X509_ALGORS to ASN1:
I want to encode a new CRL's (X509_CRL_new), currently invalid, Signing
algorithm (i2d_X509_ALGOR( crl-siging_alg, ... ) ) and restore that
with d2i_X509_ALGOR( crl-signing_alg, ...) afterwards. Restoring of
the algorithm works fine in OpenSSL 1.0.1.f, but fails in OpenSSL 1.0.1j
and 1.0.1l. This is probably because the i2d function encodes the
(invalid) Signing algorithms slightly different in the different
versions. This happens, because the invalid signing algorithm is
represented slightly different in the internal structure.
In version 1.0.1f the invalid algorithm is encoded as sequence with an
object id with length 1 and content 00 ( - 30 03 06 01 00). In the
newer versions (1.0.1j and 1.0.1l) the invalid algorithm gets encoded
as sequence with an object id of length 0 ( - 30 02 06 00). This new
encoding causes the d2i function to fail. Now the d2i function nulls
the sig_alg. This causes a X509_CRL_verify to cause a segfault.
Is this behavior expected? Am I doing something wrong? Is there a
problem with what X509_CRL_new does (setting different
UNDEFINED-ObjectId-Objects)?
For better clarifying my problem, I have attached a small example code
that creates such a CRL, tries to verify it (what will fail, but not
crash), does the i2d, d2i re-setting of the Algorithm and re-calls
X509_CRL_verify which now crashes in 1.0.1j and 1.0.1l, but works fine
in 1.0.1.f.
For executing the sample, compile it with something like gcc -g
-std=c99 crl.c $YOUR_LIBCRYPTO and attach the version of libcrypto
you want to test with.
The example should segfault with 1.0.1j and 1.0.1l but run fine with 1.0.1f.
Thank you very much for your help,
Kind regards,
Felix
#include openssl/ssl.h
#include openssl/err.h
#include stdio.h
int main( int argc, char *argv[] ) {
ERR_load_crypto_strings();
// Generate some Public key
EVP_PKEY_CTX *ctx;
EVP_PKEY *pkey = NULL;
ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
if (!ctx)
exit(-1);
if (EVP_PKEY_keygen_init(ctx) = 0)
exit(-1);
if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048) = 0)
exit(-1);
if (EVP_PKEY_keygen(ctx, pkey) = 0)
exit(-1);
// Generate a new CRL
X509_CRL *crl = X509_CRL_new();
unsigned char buffer[256];
unsigned char *pos = buffer;
// DER encode its X509 ALGORITHM
i2d_X509_ALGOR( crl-sig_alg, pos);
printf(output: %d\n, (int) ( pos - buffer) );
ERR_print_errors_fp(stdout);
// Verification fails (but does not crash)
int i = X509_CRL_verify( crl, pkey );
printf(verify: %d\n, i);
ERR_print_errors_fp(stdout);
for( int i = 0; i 5;i++){
printf(%x , (unsigned int) buffer[i] );
}
printf(\n);
printf(%x\n, (unsigned int) crl-sig_alg-algorithm);
const unsigned char *pos2 = buffer;
// This is the broken output of openssl 1.0.1j, 1.0.1l and correct (30 02
06 01 00) in 1.0.1f
/*buffer[0] = 0x30;
buffer[1] = 0x02;
buffer[2] = 0x06;
buffer[3] = 0x00;*/
ERR_print_errors_fp(stdout);
d2i_X509_ALGOR( crl-sig_alg, pos2, 9); // this nulls crl-sig_alg with
the broken output see above
printf(%d\n, (int) ( pos2 - buffer) );
i = X509_CRL_verify( crl, pkey ); // this finally crashes in 1.0.1j, 1.0.1l
but works great in 1.0.1.f
printf(verify: %d\n, i);
// Free things, if the program is still running.
ERR_print_errors_fp(stdout);
EVP_PKEY_free( pkey );
EVP_PKEY_CTX_free( ctx );
X509_CRL_free( crl );
}
---End Message---
signature.asc
Description: OpenPGP digital signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL source reformat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Matt, first of all: THANK YOU! This has been overdue for ages! Just a small tweak that would be nice I'd like to see would be to always have block markers for loops and conditions. The lack of those was one of the many pitfalls with the old source especially as the indentation had been off by one level in contrast to common rules. Including the the block markers (AKA curly brackets) at all times even for single statements has two advantages: - - You always have a block grouping statements to the proper statement - - You won't create a Apple-Style Goto Fail that easily AFAIK indent should support adding all of them automagically; otherwise astyle is another powerful solution. Anyway: BIG THANKS for finally making the code readable*. Kind regards, BenBE. *Comprehensible is a different kettle of fish ;-) Am 05.01.2015 um 13:09 schrieb Matt Caswell: We have previously announced our intention to reformat the entire codebase into a more consistent style (see our roadmap document here: https://www.openssl.org/about/roadmap.html) Since then we have been busy working towards doing that. I'd like to make available for comment a sample reformat. So far I've run it for master and 1.0.2, but the current thinking is that this will also be applied to 1.0.1, 1.0.0 and 0.9.8 (this is necessary to significantly ease the maintenance overhead) I've put the results of the reformat up on my github account here: https://github.com/mattcaswell/openssl The reformat of master is on the sample-master-reformat branch, and the 1.0.2 reformat is on sample-1.0.2-reformat. The style itself is heavily influenced by the Linux Kernel Coding style: https://www.kernel.org/doc/Documentation/CodingStyle Although there are some significant differences - most notably that we are using spaces not tabs for indents, and the indent depth is 4 characters not 8. We will be publishing our own style guide in due course. I'm not looking to open any religious wars here - so I'm not looking for comments on the style itself (e.g. debates about whether 2, 4 or 8 character indents are better (we've already had those!)) - but I'm mainly seeking feedback on anywhere where the reformatting has failed. We've already looked of course...but sometimes many sets of eyes are better! I've also made available the script that was used to do the reformatting. The script is called openssl-format-source and is in the util directory of the branches mentioned above. This script depends on GNU indent being available. It should be executed from the root of the source tree as follows: util/openssl-format-source -v -c . There are also some one-off manual tweaks (both before and after running the script) that need to be done which are present in the sample reformat branches. These are related to multi-line comments which have their own internal formatting - these aren't handled too well. The manual steps should be a one-off exercise though. The hope is that we will be able to re-run the script at regular intervals. Thanks Matt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUrB67AAoJEPHTXLno4S6tdR0P/R7MQGYZ5cRErk/55luMZLgi Om9JmXBa4NCKedVVUXLQOlkiWu4Oa3s/J0xezTwzCR5P+B9x0miDUMjm9yKy6g4q t3mhAAiGOKfofLVq7M6iOE72SO2Pd4FTCywVMPuE6p9vAK7o/Gufn/8W52ud8oBb l7O5l2o6B0191q+6v3oLb8zY028FESrJgTDfq4htzvVlOkl3mnzvXP87juyrEzIb Y4FY7DzGi146mkRro3Q3Yb0fQcNTvVajQyAMLsLTRWDSXFs998BFxMih3hlJa+gc SvPi/rjE/gNaRxB3obc0o48hdy3Q7Q6DvpxVqwxb7Y2i3kWwJaCRCcOsEvYhfqkt 5kevKe/exKEyDWtjokWat9alB/Qla6Yb725OjOo4UQvmjT2OwULB9uFoXxig3/H/ oBES33FAAU0Kul4YwmfWb17m2QWeXHcqTITXUuS2zasMxF+2wbgb5o3bcQx7QUnd Fxf4emHb9OVqLdiN7WyNkUBceot2IBB73hud2myfKZS9g71F5hhsdsXvoWp5e3/I Cp1hnD2ViE5hWF4bGbKM7Eom9IeEho1idKCGGhfgRJ2tjweP66ORZnUK+Dz84N7a Je1peZ95uAUCy2F/PI2QFpxgvSU9lHiHGpRoEQRGbCn0N24La6mi0B7APjhWgHXk tiPO8GEKG7W5TGq0thzL =iwE9 -END PGP SIGNATURE- ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [PATCH] User can choose the public exponent in genrsa
Hi,
Am 14.11.2014 um 19:07 schrieb Viktor Dukhovni:
On Fri, Nov 14, 2014 at 11:47:11AM -0600, Quentin Gouchet wrote:
@@ -139,6 +140,22 @@ int MAIN(int argc, char **argv)
f4=3;
else if (strcmp(*argv,-F4) == 0 || strcmp(*argv,-f4) == 0)
f4=RSA_F4;
+else if (strcmp(*argv,-choose) == 0)
+{
+if (--argc 1) goto bad;
+exp = *(++argv);
+/* Not checking whether exp = 2**16+1 since there is
+ * no proof that small
+ * public exponent is a threat.
+ * Choosing e = 1 or e = 3 is thus possible
+ */
+if(!BN_hex2bn(bn,exp)) goto err;
+if(!BN_is_odd(bn))
+{
+BIO_printf(bio_err,Public exponent e has to be
odd\n);
+goto err;
+}
+}
#ifndef OPENSSL_NO_ENGINE
else if (strcmp(*argv,-engine) == 0)
{
* The -choose option is too vague. Every option is a choice,
Better would be -public_exponent.
* Small public exponets ARE a threat, and in particular e=3
MUST be avoided. While e=5 or e=17 are somewhat less
risky, I'd steer clear of these also.
Fielded system with e set to something other than 3 or 65537
are rare. Are custom public exponents really a good idea? Seems
like unnecessary flexibility for the user to mess up. I'd bolt it
down at 65537 and remove all other options.
Please don't bolt down at a fixed value, but instead only check sanity
of the choosen values. I use non-standard value for e in several places
and bolting things down on one value will cause trouble should we
someday discover that even 65537 is a bad choice, but an even bigger
exponent needs to be used instead.
Already now we have a problem with being limited to about 192 bit
effective security due to arbitrary limitations in the code[1]. As
explained there when using client certificates you are bound to 128 bit
as your certificate (if not ECC) becomes the limiting factor. Overcoming
those limits is hard enough as it stands. Let alone that the library
claims to be written without artificial restrictions.
Using non-standard exponents should be hard (and AFAIK there is a way
currently implemented already, it's just hardly documented anywhere),
such that you cannot plausibly deny you didn't know what you were doing,
but the library shouldn't throw rocks in your way either when you do.
Thus I'd prefer to skip this patch (for the reasons mentioned already by
others) and either do no change OR just add proper validations for the
exponent chosen by the user.
Kind regards,
BenBE.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747453
signature.asc
Description: OpenPGP digital signature
Re: [LibReSSL] Allow key generation to use arbitrary public exponents
Hi Annie, Am 09.08.2014 19:24, schrieb Annie Yousar: Hi Ben, you can generate keys with arbitrary exponents using the genpkey command: openssl genpkey -algorithm rsa \ -pkeyopt rsa_keygen_bits:16384 -pkeyopt rsa_keygen_pubexp:4711 Thanks for this information. Now that you mention this: I read about it in the documentation. But unfortunately genpkey and genrsa produce slightly different output (plain RSA key vs. publicKeyInfo) - thus having such a -pkeyopt like interface available uniformly for genrsa, gendsa and ec might be useful. Regards, Ann. Regards, BenBE. Am 09.08.2014 15:21, schrieb Benny Baumann: Hi, I'd like to propose to include the following additional two command line arguments for the openssl binary when creating RSA keys. While the patch is written to apply to LibReSSL 2.0.5 it should apply to genrsa.c of OpenSSL 1.0.1 just fine too. While the default of 65537 is a sane default it's not strictly forced by any standard. In contrast when looking at NIST SP-800-56B section 6.2.1 bullet 2b it is described as an odd positive integer such that 65537 = e 2**256 As the plain RSA only requires e to be co-prime to both p-1 and q-1 and given the obvious limitation for e=1 yielding no security, there is no mathematical backing for any upper bound for e (except the obvious one given by p*q-1). The change only affects the key generation and extends the possibility to use custom public exponents as has been done in certain areas previously. Implementations conforming to the mathematical foundation should be unaffected as otherwise they would have been broken for decryption all along. Kind regards, Benny Baumann __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org signature.asc Description: OpenPGP digital signature
[LibReSSL] Allow key generation to use arbitrary public exponents
Hi,
I'd like to propose to include the following additional two command line
arguments for the openssl binary when creating RSA keys. While the patch
is written to apply to LibReSSL 2.0.5 it should apply to genrsa.c of
OpenSSL 1.0.1 just fine too.
While the default of 65537 is a sane default it's not strictly forced by
any standard. In contrast when looking at NIST SP-800-56B section 6.2.1
bullet 2b it is described as an odd positive integer such that 65537 =
e 2**256
As the plain RSA only requires e to be co-prime to both p-1 and q-1 and
given the obvious limitation for e=1 yielding no security, there is no
mathematical backing for any upper bound for e (except the obvious one
given by p*q-1).
The change only affects the key generation and extends the possibility
to use custom public exponents as has been done in certain areas
previously. Implementations conforming to the mathematical foundation
should be unaffected as otherwise they would have been broken for
decryption all along.
Kind regards,
Benny Baumann
diff -r -U3 '--exclude=*.log' '--exclude=*.o' libressl-2.0.5/apps/genrsa.c libressl-2.0.5-benbe1/apps/genrsa.c
--- libressl-2.0.5/apps/genrsa.c 2014-08-06 05:27:41.0 +0200
+++ libressl-2.0.5-benbe1/apps/genrsa.c 2014-08-09 01:18:37.906651418 +0200
@@ -101,6 +101,7 @@
const EVP_CIPHER *enc = NULL;
unsigned long f4 = RSA_F4;
char *outfile = NULL;
+ char *pubval = NULL;
char *passargout = NULL, *passout = NULL;
#ifndef OPENSSL_NO_ENGINE
char *engine = NULL;
@@ -127,6 +128,13 @@
if (--argc 1)
goto bad;
outfile = *(++argv);
+ } else if (strcmp(*argv, -pub) == 0) {
+ if (--argc 1)
+goto bad;
+ pubval = *(++argv);
+ f4 = 1;
+ } else if (strcmp(*argv, -pubrand) == 0) {
+ f4 = 0;
} else if (strcmp(*argv, -3) == 0)
f4 = 3;
else if (strcmp(*argv, -F4) == 0 || strcmp(*argv, -f4) == 0)
@@ -193,6 +201,8 @@
BIO_printf(bio_err, -passout argoutput file pass phrase source\n);
BIO_printf(bio_err, -f4 use F4 (0x10001) for the E value\n);
BIO_printf(bio_err, -3 use 3 for the E value\n);
+ BIO_printf(bio_err, -pub hexuse the given hex number for the E value\n);
+ BIO_printf(bio_err, -pubranduse a randomly generated number half the size of N for the E value\n);
#ifndef OPENSSL_NO_ENGINE
BIO_printf(bio_err, -engine e use engine e, possibly a hardware device.\n);
#endif
@@ -227,7 +237,28 @@
if (!rsa)
goto err;
- if (!BN_set_word(bn, f4) || !RSA_generate_key_ex(rsa, num, bn, cb))
+ switch( f4 ) {
+ case 0:
+ if(!BN_rand(bn, num 1, 0, 1))
+goto err;
+ break;
+
+ case 1:
+{
+ BIGNUM *tmp;
+ if(!BN_hex2bn(tmp, pubval))
+goto err;
+ if(!BN_copy(bn, tmp))
+goto err;
+ break;
+}
+ default:
+ if (!BN_set_word(bn, f4))
+goto err;
+ break;
+ }
+
+ if (!RSA_generate_key_ex(rsa, num, bn, cb))
goto err;
/*
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Kurt, Am 04.07.2014 00:41, schrieb Kurt Roeckx: On Thu, Jul 03, 2014 at 11:42:08PM +0200, Wilfried Klaebe wrote: Am Thu, Jul 03, 2014 at 07:20:46PM +0200 schrieb Kurt Roeckx: On Thu, Jul 03, 2014 at 08:08:52AM -0400, Hubert Kario wrote: - Original Message - From: Benny Baumann be...@geshi.org To: openbsd-t...@openbsd.org, openssl-dev@openssl.org Sent: Wednesday, 2 July, 2014 8:49:18 PM Subject: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions Hi folks, I know the following patches will cause a controversy just like the issues they resolve caused me and several other people headaches when debugging them. But first things first. The attached patches (intentionally) do the following two things: 1. Adjust the limit for maximum allowed size of a received public key to be increased from 516 bytes (just barely enough for 4 KBit RSA public keys) up to 8200 bytes (enough for 64KBit RSA keys with some minor margin) 2. Remove the crippling of the DH/DSA routines for working with at most 10kBit parameters. Current general recommendation is that if you require more than 128 bit security you shouldn't be using RSA or DHE in the first place but use ECC. You'd need someone signing your ECC certificates though. There are CAs doing ECC certificates. I see about 100 that trace back to the mozilla certificate store. They might not be popular, but it does exist and is being used. Sure. But still people are free to choose their CA for other parameters. Also people ARE using 8192 RSA certificates in the wild and with server certificates this is no problem. Currently things break horrible with client certificates of this size - for NO good reason. Just generating 16k DH params takes inordinate amount of time. With 4096 bit DH parameters I'm getting less than 20 key exchanges a second with a fast i7 CPU. I'd hazard a guess that with 16k DH you'll be able to do less than 1 key exchange a second. That's a very neat way to DoS your server. That's why Benny suggested making the limit configurable instead of flatly raising it. But the patch just raises the limit to something I think you shouldn't consider using. If you read my first mail you /might/ have found a paragraph stating that I'm well open for discussion given one of two things is honored with the choosen solution: 1. Either do a fix limit at 65536 Bit (as it's now) 2. OR do a dynamic limit with a default at the next level above the currently wide used size (8192 Bit) With the first option I offered a limit as low as 16384 Bit which unfortunately due to it's implementation affects all public keys transmitted to the server. Not fixing this means having inconsistent behaviour between RSA and DSA when both offer similar strength - DSA being limited at 10k while RSA breaking at 4k. By adjusting the limit you could get this to at least be consistently breaking at 16k regardless of whether you use RSA or DSA. Unfortunately adjusting DSA also involves adjusting DH, because the limit is implemented *in*the*bignum*library* - one of the worst places to do so. That's why I said DSA/DH is crippled: You just might want to allow arbitrary sizes for keys in the offline case and limit things in the online case - if you are at arguing with the performance part of things. According to the NIST recommendations (http://www.keylength.com/en/4/), 16384 bit would be close to the 15360 bit if you want to reach the 256 bit level. But there currently is no way to reach the 256 level with TLS as far as I know. The best you can currently do is 192 bit, which The most you can get is 192 Bit using SHA384 based ciphers with either RSA, DSA or EC curve P-571. would be a 7680 assymetric key. So I think that anything above 8192 bit doesn't make any sense at the moment. Granted. 8k is the max I currently use and what I have seen in the wild - but 8192 bit IS being used to a point where it starts to matter. Considering that #319 is unresolved for nearly 12 years now, and part 1 of this patch would at least mitigate that one for quite some time into the future, could the OpenSSL Project please apply at least that one really soon now, please? It got applied 12 years ago? Just not to the limit you want now. Nope. It was fixed in 2004 earliest if I read the comments in that ticket correctly. And even then it took them TWO YEARs two change one number holding everyone back Wouldn't it be better to be proactive here and be one step ahead by allowing 8192 Bit certificates if people really want to use them (and I WANT to use them). The current limit is breaking software and thus it IS a bug. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -BEGIN
[PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
Hi folks,
I know the following patches will cause a controversy just like the
issues they resolve caused me and several other people headaches when
debugging them.
But first things first. The attached patches (intentionally) do the
following two things:
1. Adjust the limit for maximum allowed size of a received public key to
be increased from 516 bytes (just barely enough for 4 KBit RSA public
keys) up to 8200 bytes (enough for 64KBit RSA keys with some minor margin)
2. Remove the crippling of the DH/DSA routines for working with at most
10kBit parameters.
Find the patches attached to this mail. As the patches were originally
submitted as part of Debian Bug #747453 [1] they are in Debian format
suiteable for automatic application by the Debian tools. The patches
apply (automatically) to the latest released OpenSSL 1.0.1 version.
At the Debian BTS you can also find some of the previous discussion of
those patches.
The problems fixed by those patches surfaced for me in two different
situations both being related in nature and both having in common that
debugging was non-trivial due to no meaningful error messages being
returned.
The first issue affects OpenSSL clients connecting to server with DH
parameters using a prime larger than 10kBit. While other libraries
(GnuTLS and libNSS) handle this without problems OpenSSL simply barks
and closes the connection. Debugging this issue required several hours
of studying network dumps and circling around in the OpenSSL source
without much success.
The second issue took about 2 weeks of debugging eJabberd instances
returning misleading error messages: Even though both eJabberd servers
happily talked to each other in plain (before STARTTLSing to something
secure) they failed with a remote-host-not-found error when mutually
authenticating each other (both servers use properly signed 8KBit RSA
keys as server certificates). The cause was finally found only by chance
when the certificates where replaced by smaller keys for testing (Usage
of 8KBit RSA is common with both server admins involed with this
debugging session).
Please find more details in the Debian BTS - or feel free to ask.
The modifications (new boundaries) are open for discussion as long as
the following conditions are met:
- a security level of 256 Bit equivalent strength can be reached for the
used certificate (which means ~16KBit RSA for Client Certs)
OR
- the limit can be adjusted by software and defaults to at least 192
bits of symmetric security.
Looking forward to seeing those patches or a modification thereof in an
upcoming release.
Kind regards,
Benny Baumann
[1] https://bugs.debian.org/747453
Description: Increase the maximum size allowed for client/server certificate packages on the wire
Author: Benny Baumann be...@geshi.org
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- openssl-1.0.1e.orig/ssl/s3_srvr.c
+++ openssl-1.0.1e/ssl/s3_srvr.c
@@ -2926,7 +2926,7 @@ int ssl3_get_cert_verify(SSL *s)
SSL3_ST_SR_CERT_VRFY_A,
SSL3_ST_SR_CERT_VRFY_B,
-1,
- 516, /* Enough for 4096 bit RSA key with TLS v1.2 */
+ 8200, /* Enough for 65536 bit RSA key with TLS v1.2 */
ok);
if (!ok) return((int)n);
Description: Remove DSA/DH keysize restrictions
Author: Benny Baumann be...@geshi.org
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- openssl-1.0.1e.orig/crypto/dsa/dsa.h
+++ openssl-1.0.1e/crypto/dsa/dsa.h
@@ -84,10 +84,6 @@
#endif
#endif
-#ifndef OPENSSL_DSA_MAX_MODULUS_BITS
-# define OPENSSL_DSA_MAX_MODULUS_BITS 1
-#endif
-
#define DSA_FLAG_CACHE_MONT_P 0x01
#define DSA_FLAG_NO_EXP_CONSTTIME 0x02 /* new with 0.9.7h; the built-in DSA
* implementation now uses constant time
--- openssl-1.0.1e.orig/crypto/dsa/dsa_ossl.c
+++ openssl-1.0.1e/crypto/dsa/dsa_ossl.c
@@ -325,11 +325,6 @@ static int dsa_do_verify(const unsigned
return -1;
}
- if (BN_num_bits(dsa-p) OPENSSL_DSA_MAX_MODULUS_BITS)
- {
- DSAerr(DSA_F_DSA_DO_VERIFY
