Re: Preferred way of passing user context void* inside SSL*
On 23.10.19 15:21, Salz, Rich wrote: >>Is there a way for me to piggyback a void* inside the SSL structure so > that I can access it from within the callback? > > Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented > in https://github.com/openssl/openssl/pull/10216 (and due to be merged to > master soon) Ah, completely overlooked that! Thanks, Rich, this scratches *exactly* my itch. All the best, Joe
Preferred way of passing user context void* inside SSL*
Hi list, yet another question. In my process with TLS13-PSK, I've noticed that the PSK callback does not have a user-definable callback context value. However, the callback is passed the SSL* which I created when the session was established. Is there a way for me to piggyback a void* inside the SSL structure so that I can access it from within the callback? I've noticed a couple of member variables that might be abused for this purpose (async_cb_arg, allow_early_data_cb_data, default_passwd_callback_userdata, msg_callback_arg) and think in my usecase they hopefully should all be safe to use (I don't use async I/O, no early data, no SRP, no msg callback) -- but is this the preferred way to do it? I.e., hijack a different callback argument that isn't used? Am I overlooking the supposed way of doing this? Or is this typically done via global variables (which in my case I *really* would want to avoid)? Cheers, Johannes
Re: PSK with TLSv1.3
On 23.10.19 11:24, Johannes Bauer wrote:
> All error checking omitted for now, this is obviously just a sample.
> When I try to connect to my server on the command line using s_client:
>
> $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122
>
> The server pukes:
>
> PSK server SSL 0x62300100 identity foo len 3 sess (nil)
> 139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad
> extension:../ssl/statem/extensions_srvr.c:1267:
>
> And I have no idea what that's supposed to mean.
One step further... I've peeked at s_server.c and copied some of that
code. I.e., concretely I now am at:
const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 };
const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_id);
if (!cipher) {
return 0;
}
SSL_SESSION_set_cipher(sess, cipher);
But, uhm... this is positively terrifying code. Is this how it's
supposed to look, i.e., hard-coded magic numbers in the application?! Or
is that just the route s_server took and there's a preferred, better way?
In any case, while it throws a different error message now, it still
does not work:
PSK server SSL 0x6230fd00 identity foo len 3 sess (nil)
140710464452352:error:14201076:SSL routines:tls_choose_sigalg:no
suitable signature algorithm:../ssl/t1_lib.c:2649:
I've never in the setup limited the signature algorithms and s_client
does not, either (when I peek at the ClientHello it advertises a whole
bunch of signature algorithms).
Any advice?
Thank you,
Johannes
PSK with TLSv1.3
Hi list,
I'm in the process of refactoring/updating code that has been using
TLS-PSK with TLSv1.2 for a number of years successfully. I want to
upgrade it so that it uses TLSv1.3 exclusively.
I find it *exceptionally* hard to wrap my head around the new API and
the documentation/manpages are extremely confusing to me.
E.g., while
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_psk_use_session_callback.html
mentions specifically TLSv1.3 clients, there's no mention of server
implementation and the text does not seem to have been updated for
TLSv1.3 entirely (e.g., there's mention of "the callback" -- clearly
previously there was only one, now there's two,
SSL_psk_use_session_cb_func and SSL_psk_client_cb_func).
I'm struggling with all of it, in particular the way the server callback
works in TLSv1.3: What I'm doing now is register a
static int psk_server_callback(SSL *ssl, const unsigned char *identity,
size_t identity_len, SSL_SESSION **sessptr);
using
SSL_CTX_set_psk_find_session_callback(cctx, psk_server_callback);
Then, inside the callback I create a SSL_SESSION* in the callback (if I
want to return a PSK) using SSL_SESSION_new(). Setting the master key
(that's the PSK, right?) using SSL_SESSION_set1_master_key and the
protocol version using SSL_SESSION_set_protocol_version is straightforward.
But what the heck am I supposed to do with SSL_SESSION_set_cipher? The
text in
https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html
does not contain any hint on what to do in the server case and the text
provided in the client manpage is exceedingly confusing:
"Only the handshake digest associated with the ciphersuite is relevant
for the PSK (the server may go on to negotiate any ciphersuite which is
compatible with the digest). The application can use any TLSv1.3
ciphersuite."
So, wait, I can use any TLSv1.3 ciphersuite but it's not relevant
because only the MD of the suite is used, everything else is discarded?
So I return a cipher suite value, but it doesn't have to do anything
with the cipher suites that I allow, it's just a "wrapper" for a MD?
Here's what I'm doing right now in my server callback:
static int psk_server_callback(SSL *ssl, const unsigned char *identity,
size_t identity_len, SSL_SESSION **sessptr) {
fprintf(stderr, "PSK server SSL %p identity %s len %ld sess %p\n", ssl,
identity, identity_len, *sessptr);
SSL_SESSION *sess = SSL_SESSION_new();
SSL_SESSION_set1_master_key(sess, (const unsigned char*)"\x00\x11\x22",
3);
SSL_SESSION_set_cipher(sess, SSL_get_pending_cipher(ssl));
SSL_SESSION_set_protocol_version(sess, TLS1_3_VERSION);
*sessptr = sess;
return 1;
}
All error checking omitted for now, this is obviously just a sample.
When I try to connect to my server on the command line using s_client:
$ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122
The server pukes:
PSK server SSL 0x62300100 identity foo len 3 sess (nil)
139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad
extension:../ssl/statem/extensions_srvr.c:1267:
And I have no idea what that's supposed to mean.
I'm willing to update the documentation/manpage and create a PR, but I
don't understand it as-it right now. So any help getting me up to speed
would be greatly appreciated. Examples would be also extremely useful
for this.
All the best,
Johannes
[openssl-users] openssl dgst computes wrong HMAC?
Hi list,
when I use OpenSSL I suspect some funny business going on with the HMAC
computation of openssl dgst command line tool. Consider:
$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
(stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
But
#include stdio.h
#include stdint.h
#include stdbool.h
#include openssl/hmac.h
#include hexdump.h
int main() {
uint8_t digest[32];
HMAC_CTX hmacCtx;
HMAC_CTX_init(hmacCtx);
HMAC_Init_ex(hmacCtx, \xaa\xbb\xcc, 3, EVP_sha256(), NULL);
HMAC_Update(hmacCtx, foobar, 6);
unsigned int length;
HMAC_Final(hmacCtx, digest, length);
HMAC_CTX_cleanup(hmacCtx);
HexDump(digest, 32);
return 0;
}
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Also, Python:
#!/usr/bin/python3
import Crypto.Hash.HMAC
import Crypto.Hash.SHA256
key = b\xaa\xbb\xcc
data = bfoobar
hmac = Crypto.Hash.HMAC.new(digestmod = Crypto.Hash.SHA256, key = key)
hmac.update(data)
result = hmac.digest()
print(.join(%02x % (c) for c in result))
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Am I using openssl dgst wrong or is it just plain broken?
Regards,
Johannes
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
On 03.02.2015 10:00, Johannes Bauer wrote: when I use OpenSSL I suspect some funny business going on with the HMAC computation of openssl dgst command line tool. Consider: Damn, I'm sorry. Forgot to include the version: OpenSSL 1.0.1f 6 Jan 2014 Regards, Johannes ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl dgst computes wrong HMAC?
Hi list,
when I use OpenSSL I suspect some funny business going on with the HMAC
computation of openssl dgst command line tool. Consider:
$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
(stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
But
#include stdio.h
#include stdint.h
#include stdbool.h
#include openssl/hmac.h
#include hexdump.h
int main() {
uint8_t digest[32];
HMAC_CTX hmacCtx;
HMAC_CTX_init(hmacCtx);
HMAC_Init_ex(hmacCtx, \xaa\xbb\xcc, 3, EVP_sha256(), NULL);
HMAC_Update(hmacCtx, foobar, 6);
unsigned int length;
HMAC_Final(hmacCtx, digest, length);
HMAC_CTX_cleanup(hmacCtx);
HexDump(digest, 32);
return 0;
}
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Also, Python:
#!/usr/bin/python3
import Crypto.Hash.HMAC
import Crypto.Hash.SHA256
key = b\xaa\xbb\xcc
data = bfoobar
hmac = Crypto.Hash.HMAC.new(digestmod = Crypto.Hash.SHA256, key = key)
hmac.update(data)
result = hmac.digest()
print(.join(%02x % (c) for c in result))
Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e
Am I using openssl dgst wrong or is it just plain broken?
Regards,
Johannes
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
On 03.02.2015 10:00, Johannes Bauer wrote: when I use OpenSSL I suspect some funny business going on with the HMAC computation of openssl dgst command line tool. Consider: Damn, I'm sorry. Forgot to include the version: OpenSSL 1.0.1f 6 Jan 2014 Regards, Johannes ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl dgst computes wrong HMAC?
On 03.02.2015 11:16, Billy Brumley wrote: $ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c This gets posted every once in a while -- google around. Something about the hmac switch not doing what you think it's doing. $ echo -n foobar | openssl dgst -sha256 -mac HMAC -macopt hexkey:aabbcc (stdin)= 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e Ah, interesting. I did google the issue, but only found post of people who didn't realize that echo without -n appends a newline. If this topic really comes up every now and then, I'd still suggest updating the help page to clarify while remaining identical behavior. Currently it reads -hmac argset the HMAC key to arg. I would suggest -hmac strset the HMAC key to the string str. Regards, Johannes ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: TLS v1.2 problems with connection establishment No shared ciper
On 15.05.2013 23:05, Dr. Stephen Henson wrote: On Wed, May 15, 2013, Johannes Bauer wrote: Does this mean that communication with TLS1.2 with curves other than the SEC-curves has actually never worked with OpenSSL (because it couldn't have worked as this would require the explicit curve type why doesn't appear to be implemented as of now)? Or is there some workaround through which I could get it to run? Yes that's correct. At present the explicit curve type isn't supported. Oh no. :-( Is it anywhere near on the roadmap (so I could sit it out) or is this nothing that's of particular interest to OpenSSL development? Any way I could contribute in pushing this forward (i.e. is it just some fixes here and there in the codebase or does it require major effort)? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
TLS v1.2 problems with connection establishment No shared ciper
Hi list, I'm having trouble getting a TLS 1.2 with EC F_p certificates to run. This is my setup: Server: openssl 1.0.1e compiled from source, Debian squeeze Client: openssl 1.0.1c from Gentoo tree On the Server, i get $ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=AES(256) Mac=SHA1 SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=3DES(168) Mac=SHA1 SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=3DES(168) Mac=SHA1 EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 PSK-3DES-EDE-CBC-SHASSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=AES(128) Mac=SHA1 SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 DHE-RSA-SEED-SHASSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHASSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2
Re: TLS v1.2 problems with connection establishment No shared ciper
On 15.05.2013 17:48, Johannes Bauer wrote: Server: openssl 1.0.1e compiled from source, Debian squeeze Client: openssl 1.0.1c from Gentoo tree Additional info: Just upgraded the Client to 1.0.1e (Gentoo) and have the same issue. Something is *seriously* wrong here. That's what the server says when debugging is enabled: Using default temp DH parameters Using default temp ECDH parameters ACCEPT SSL_accept:before/accept initialization read from 0x1767390 [0x176ca80] (11 bytes = 11 (0xB)) - 16 03 01 01 3d 01 00 01-39 03 03 =...9.. read from 0x1767390 [0x176ca8e] (311 bytes = 311 (0x137)) - 51 93 d9 ca cb e4 b0 0b-bd 3a 70 45 fd f8 6a f6 Q:pE..j. 0010 - c5 c6 a6 07 33 ea 2b ff-69 a1 f2 d5 55 3b f1 ca 3.+.i...U;.. 0020 - 00 00 a0 c0 30 c0 2c c0-28 c0 24 c0 14 c0 0a c0 0.,.(.$. 0030 - 22 c0 21 00 a3 00 9f 00-6b 00 6a 00 39 00 38 00 .!.k.j.9.8. 0040 - 88 00 87 c0 32 c0 2e c0-2a c0 26 c0 0f c0 05 00 2...*.. 0050 - 9d 00 3d 00 35 00 84 c0-12 c0 08 c0 1c c0 1b 00 ..=.5... 0060 - 16 00 13 c0 0d c0 03 00-0a c0 2f c0 2b c0 27 c0 ../.+.'. 0070 - 23 c0 13 c0 09 c0 1f c0-1e 00 a2 00 9e 00 67 00 #.g. 0080 - 40 00 33 00 32 00 9a 00-99 00 45 00 44 c0 31 c0 @.3.2.E.D.1. 0090 - 2d c0 29 c0 25 c0 0e c0-04 00 9c 00 3c 00 2f 00 -.).%/. 00a0 - 96 00 41 00 07 c0 11 c0-07 c0 0c c0 02 00 05 00 ..A. 00b0 - 04 00 15 00 12 00 09 00-14 00 11 00 08 00 06 00 00c0 - 03 00 ff 02 01 00 00 6f-00 0b 00 04 03 00 01 02 ...o 00d0 - 00 0a 00 34 00 32 00 0e-00 0d 00 19 00 0b 00 0c ...4.2.. 00e0 - 00 18 00 09 00 0a 00 16-00 17 00 08 00 06 00 07 00f0 - 00 14 00 15 00 04 00 05-00 12 00 13 00 01 00 02 0100 - 00 03 00 0f 00 10 00 11-00 23 00 00 00 0d 00 22 .#. 0110 - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01 . .. 0120 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03 0130 - 01 01 00 0f 00 01 01 ... TLS 1.2 Handshake [length 013d], ClientHello 01 00 01 39 03 03 51 93 d9 ca cb e4 b0 0b bd 3a 70 45 fd f8 6a f6 c5 c6 a6 07 33 ea 2b ff 69 a1 f2 d5 55 3b f1 ca 00 00 a0 c0 30 c0 2c c0 28 c0 24 c0 14 c0 0a c0 22 c0 21 00 a3 00 9f 00 6b 00 6a 00 39 00 38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0 13 c0 09 c0 1f c0 1e 00 a2 00 9e 00 67 00 40 00 33 00 32 00 9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02 01 00 00 6f 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00 0d 00 22 00 20 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01 01 write to 0x1767390 [0x1776570] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 28 ..( TLS 1.2 Alert [length 0002], fatal handshake_failure 02 28 SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client hello C SSL_accept:error in SSLv3 read client hello C ERROR 139635277244072:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1355: shutting down SSL CONNECTION CLOSED ACCEPT Hopefully someone can help me, Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS v1.2 problems with connection establishment No shared ciper
On 15.05.2013 20:52, Dave Thompson wrote: I can't easily test at the moment (even assuming your client is OpenSSL), but I speculate that in SSL3 mode the client doesn't send (Client)Hello extensions for SupportedCurves and SupportedPointFormats, Correct. and in TLS mode(s?) it does. Correct again. If those extensions are present but don't include the named curve or unnamed generic type (your case) and pointformat used by your EC cert/key, Pointformat shouldn't be the problem as I'm not using point compression. But indeed the TLS 1.2 client only sends a list of 25 permissible curves. Only sect/secp are included curiously although my openssl client does internally also know, for example, about the wap-wsg and X9.62 curves. But those are not included in the Client Hello request. And there's definitely no unnamed generic type included in the request. Is there any way I can make openssl include that? OpenSSL server logic won't consider that EC cert/key as a candidate for this client/session. Unless there's another cert/key configured, or non-PK alternatives like PSK or SRP, acceptable to the client, you'll get no shared cipher. This is highly problematic, as custom curves (like the Brainpool curves I need to use, which aren't even included in stock openssl) are then therefore rendered dysfunctional. Even worse is that even if I would somehow get the s_client/s_server test running, I ultimately need to transfer the results to openvpn (where I have even less control about openssl intrinsics). You mentioned that you aren't able to easily reproduce this -- I could provide either complete keys/certificates for testing purposes or a pcap dump (just did it to confirm your assertions about SupportedCurves and SupportedPointFormats held true). Is either going to be helpful to you? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS v1.2 problems with connection establishment No shared ciper
On 15.05.2013 21:17, Johannes Bauer wrote: Only sect/secp are included curiously although my openssl client does internally also know, for example, about the wap-wsg and X9.62 curves. But those are not included in the Client Hello request. And there's definitely no unnamed generic type included in the request. Is there any way I can make openssl include that? Interesting. I've done some poking around in the source code and RFC4492. It appears that in that NamedCurve enumeration the only named curves are indeed secp and it's twisted sister curves (apart from the generic type). So that explains why they're the only ones that appear in the enumeration. However, in the source code I couldn't find any reference to the arbitrary explicit type; searched in the nid_list in ssl/t1_lib.c and also for the constant 0xff01 (hex and decimal) and found no occurences. Does this mean that communication with TLS1.2 with curves other than the SEC-curves has actually never worked with OpenSSL (because it couldn't have worked as this would require the explicit curve type why doesn't appear to be implemented as of now)? Or is there some workaround through which I could get it to run? Thank you very much for the pointer in the right direction, Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Weird not-so-self-signed certificate
Hi list, I'm quite puzzled and hope somebody can help me. I'm handling a large number of certificates and for generating testcases for the software I employ, I wrote a small script that downloaded web server certificates en bulk and then processed them, to check for irregularities. My software barfed on a certain certificate, which is this one: -BEGIN CERTIFICATE- MIIC8TCCAdmgAwIBAgIQNmL4pIUXFpRBUK7QhJR/JjANBgkqhkiG9w0BAQUFADAg MR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFHSjgwHhcNMTAxMjIzMjAzOTU0 WhcNMjAxMjIwMjAzOTU0WjAgMR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFH SjgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6CNzdS+lWquEQndmY R1XY6cEqeMSB6YVSxXFAARRsdLQceCIpZbD5CijYklx874gOokTwSzZ7EJ6QSPUL jItM5PRlkeh0twrVEU5UTeqybAnVEciL5oVy6EPm4niYweAJrf5QCtPcORtt2Kjs xYAX2Ltl7mjvi+QM+XwDX0LKWyIjpYTZXB/5XRnpzUuBw3pDx+z4fWk8SFqN4Ptb /7fZSoxI6VeuTvrgS4aMyjsPylPnpXVAFYOcxketS0D1F9m0z5t3eD3hXesgbCHS svy0gACF3qvarJiE6MVDaJ/tlX408G9V3gEHpCCrk+yL5FiT/dtr7tNlWMt+o9D4 5/kNAgMBAAGjJzAlMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwQHAwUAsAAA ADANBgkqhkiG9w0BAQUFAAOCAQEAYvuUspk2lHiP3IM4maY2DOH0UfSsldyqOICP ue3xmqNnkhN7QBe8GIcsKt3fiozC7L+zcxdIY6L7WgGx1+aK8f3AKl/FojPegMhC WsgNy5WsR+jLUduclZDGf4qXxo9Vs1qXeP4qYZOa1rtqiBfFaQsxs4+XyFHdaB8N HzviKd8NSeCn+ZfUTKYlErUAL+qtLaQQTqVvBVnwR9yT74izZ48f0mX8zHYMFJIk mokioFqzl2ZVF98JBLSy6sNTZfO+eg98g3uDVRwq9JyvsWp1OJ94BvoXFZX7ETDM Z53Hp5s3YUNRptlIvzre/foKg4MZB8BNUsEUdgaGOeoXho7jDA== -END CERTIFICATE- It's seemingly self-signed, but then again -- not. When I call openssl: $ openssl verify -CApath /dev/null -CAfile weird.crt weird.crt weird.crt: /CN=WMSvc-WIN-EEBHLC81GJ8 error 20 at 0 depth lookup:unable to get local issuer certificate Interestingly the lookup fails at depth 0 (!). If a parent certificate were missing, I'd expect a lookup fail at depth 1. When I create a self-signed certificate: $ openssl req -new -x509 -nodes -out foobar.crt And check it then: $ openssl verify -CApath /dev/null -CAfile foobar.crt foobar.crt foobar.crt: OK I'm puzzled and before jumping to conclusions wanted to ask you first what you think of that. Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
X.509 certificate subject format
Hi list, I have a rather simple question regarding X.509 subjects that is not entirely clear to me and for which I cannot find the appropriate reference (pointers greatly appreciated). The trouble starts when trying to compare two subjects of *different* certificates for equality and becomes worse when certain fields are appearing more than once. To clarify, by equal I mean 'should behave in exactly the same way by all well-behaved implementations. Let's start easy. Consider the following subjects: subject1= /C=SE/O=FooBar/OU=BarFoo/CN=moo.koo.com subject2= /C=SE/OU=BarFoo/CN=moo.koo.com/O=FooBar Are these to be considered equal or not? I.e.: Does the order of elements matter? Does the order matter when fields are duplicate, i.e. are: subject1= /CN=foo/CN=bar subject2= /CN=bar/CN=foo equal? If they are not equal, does the first one have a special meaning? For example, assume a webserver with a duplicate common name field. Are both names valid as the server name then? I.e. could I access a webserver with the certificate subject as stated above by DNS foo *and* bar or only by one of them? One reason to ask for equality is that there maybe is a certificate X: issuerX = /O=myCA/OU=greatCA/CN=not subjectX= /CN=foo/CN=bar and it has a valid signature by a CA with the following subject: issuerX = /OU=greatCA/O=myCA/CN=not Is the certificate signature then valid? Any help is greatly appreciated! Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Triple DES ECB question
On 24.02.2012 03:51, burtbick wrote: So the new questions are: Is des-ede the proper choice for Triple DES-ECB as the target device specification requires? If not then is there another viable option? You can use 3K3DES and have the same results (with lower performance) if you set K1 = K3. Therefore, if you select your 24 byte key to be , the outcome should be the same as using X/Y with 2KDES. HTH, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 12.01.2012 19:05, Kenneth Goldman wrote: I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). It's more than valid. I think it's essential that the server omit the root. If the server supplied the entire chain, they could create the entire chain, and thus could claim to be anyone. Hmm - I disagree with that assessment. The client has to check that the root (that the server may provide or may omit) is inside the trusted certificate store of the client -- regardless of the client provides it or not. And clients (and probably therefore OpenSSL) do that, too: When I for testing purposes create and send a complete certificate path for a SSL webserver, Firefox still rejects it as it should, because no certificate is in the truststore. The root must be delivered out of band, trusted by other means. Correct. The question is just: can this root of trust be an intermediate certificate or must it be a self-signed certificate? Is this one of the checks that occurs within the OpenSSL client? To clarify what I mean, please consider the tiny picture at http://pastebin.ca/2102780 Let's say I have some ultimate root A which has issued a sub-CA B for me. I use B to create, for example, a certificate for my webserver D. Now I have clients which should only connect to webservers that have been issued by D. I configure the webserver to only send D certificate and have in my clients only one certificate in the certificate store: B. The clients cannot connect (cannot verify peer), because in the client's certificate store, A is missing (deliberately!). The reason why it is missing is the following: If I put A into the store of the clients, A might have issued a sub-CA certificate to my opponent C (which I do not have control over). C would sign a certificate for Eve which contains my server's DNS name as CN. Then when Eve would make a man-in-the-middle attack with it's fake webserver, my clients would still connect, since they can construct a path to the root A (E - C - A). I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 12.01.2012 19:23, Michael S. Zick wrote: On Thu January 12 2012, Johannes Bauer wrote: Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). It is a third party verification system that is used. How could you trust the server to tell you itself who it is? I can trust the webserver because the signature of it's certificate was verifiably created by the intermediate CA (which I trust and who's certificate the client has in its trust store). Thus, the need for obtaining the root certificate some way other than having it sent by the server in question. And yes, 'root' certificates are self-signed, signed by an 'independent' third party in the business of being trusted for that purpose. Well, the thing is: Having them self-signed is not necessary for security purposes. It apparently is what OpenSSL requires. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Well, I'm just part of the big picture ;-) Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 13.01.2012 01:02, Dave Thompson wrote: The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Yes. Or rather the libcrypto routine X509_verify_cert, used by the 'verify' utility and also the SSL handshake logic and also other applications if they wish, insists on reaching a root. Ah, I figured I'd have to go there. The reason why I was hoping to get around this is that the OpenSSL code is properly reviewed and auditted -- I would rather not write code which could have serious sercurity implications if it's broken (especially since it's not properly reviewed). Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Not in OpenSSL, unless you change the verify logic, or replace or override it with your own (which AFAICS could be done, with some effort, using the optional verify callback). It's not clear to me this is the best policy choice; IE (or I believe actually some Windows feature IE uses) and Firefox and Java (JSSE) all allow you to establish a non-root as a trust anchor. But it's what OpenSSL does, and has for a long time. Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. In my scenario this restriction actually makes the whole system less secure (since it allows a superset of certificates to be valid instead of just a tiny subset). I'll have a look into the custom verify-peer-callback and see how difficult it is and how easily it can be used. Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 13.01.2012 10:15, Curt Sampson wrote: On 2012-01-13 09:54 +0100 (Fri), Johannes Bauer wrote: Let's say I have some ultimate root A which has issued a sub-CA B for me. I use B to create, for example, a certificate for my webserver D. Now I have clients which should only connect to webservers that have been issued by D. I configure the webserver to only send D I think you meant, B there. Ah, yes. I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. I think understand exactly what you are doing and why you want to do it. (I have similar issues within a system in which I'm working.) Ah, good, then I explained it well enough :-) Do you have a solution for your scenario? Do you manually check certificates? Or is there some workaround? Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify intermediate certificate
Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl enc block size
Hello list, I'm having trouble with the openssl enc feature. This here: echo -n '0123456789abcde' | openssl enc -aes128 -nosalt -K 00112233445566778899aabbccddeeff -iv | wc -c (encoding 15 characters) results in one result block being generated: The command results in 16 (exactly one block). However, when encrypting a full block: echo -n '0123456789abcdef' | openssl enc -aes128 -nosalt -K 00112233445566778899aabbccddeeff -iv | wc -c Then two result blocks are generated (the result is 32). Why is this? A full 16 byte block should IMHO always translate to a 16 byte block in AES-128. What's wrong here? Regards, Joe -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl enc block size
Original-Nachricht padding Why would a 16 byte block need to be padded by one byte to 17 bytes? Regards, Johannes -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Changing CSR Subject
Hello list, I get CSR from people which have not necessarily set the subject values set to the correct values. Instead of forcing them to enter exact values (how I do it at the moment and which works TERRIBLY), I'd just like to change them myself and use the PK they provide within the CSR. I can do this just fine by using openssl req -in in.csr -out out.csr -subj '/O=foo' However, when I then try to sign out.csr, the signature is not correct (of course it isn't!), so I get Signature did not match the certificate request, openssl refuses to sign. Is there another way to take just the PK from the CSR and choose a custom subject for the certificate generation? Or is there some different way I'm not seeing at all? Regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Changing CSR Subject
Patrick Patterson schrieb: Check out the archives, and see my reply to Martine Schneider and David Schwartz from yesterday to the query: Sign CSR after modifying data in CSR possible? A, thanks! With openssl ca it's possible, but I've been using openssl x509 -req so far. Thanks a lot again, Kind regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
