Re: redondance signature algorithm listed in client hello
I noted there is a typo at "rsa_pkcs1_sha5256". Fix this typo, SSL_CTX_set1_sigalgs_list works as expected. Jared Huang 於 2022年9月20日 週二 下午5:34寫道： > Hello, > > > > I’m using SSL_CTX_set1_sigalgs_list to set my favorite signature algorithm. > > But there is more algorithm listed on client hello message than I desired. > > > > I defined a list > > #define TLS_PREFER_SIGNATURE"rsa_pss_rsae_sha256:" \ > > "rsa_pss_rsae_sha384:" \ > > "rsa_pss_rsae_sha512:" \ > > "rsa_pss_pss_sha256:" \ > > "rsa_pss_pss_sha384:" \ > > "rsa_pss_pss_sha512:" \ > > "ecdsa_secp256r1_sha256:" \ > > "ecdsa_secp384r1_sha384:" \ > > "ecdsa_secp521r1_sha512:" \ > > "rsa_pkcs1_sha256:" \ > > "rsa_pkcs1_sha384:" \ > > "rsa_pkcs1_sha5256" \ > > > > Then, use SSL_CTX_set1_sigalgs_list(pCtx, TLS_PREFER_SIGNATURE ) to > customize signature algorithm. > > But in client hello, the signature algorithm has more than I listed. > > Signature Hash Algorithms (23 algorithms) > > Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > > Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > > Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > > Signature Algorithm: ed25519 (0x0807) > > Signature Algorithm: ed448 (0x0808) > > Signature Algorithm: rsa_pss_pss_sha256 (0x0809) > > Signature Algorithm: rsa_pss_pss_sha384 (0x080a) > > Signature Algorithm: rsa_pss_pss_sha512 (0x080b) > > Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) > > Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) > > Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) > > Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > > Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > > Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > > Signature Algorithm: SHA224 ECDSA (0x0303) > > Signature Algorithm: ecdsa_sha1 (0x0203) > > Signature Algorithm: SHA224 RSA (0x0301) > > Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > > Signature Algorithm: SHA224 DSA (0x0302) > > Signature Algorithm: SHA1 DSA (0x0202) > > Signature Algorithm: SHA256 DSA (0x0402) > > Signature Algorithm: SHA384 DSA (0x0502) > > Signature Algorithm: SHA512 DSA (0x0602) > > > Do I make any mistake ? How do i remove SHA+DSA, and others? > > > Thanks > > -- > Sincerely, > Jared > > -- Sincerely, Jared 黃清富 Mobile: 0932-945-823 E-Mail: jared...@gmail.com
redondance signature algorithm listed in client hello
Hello, I’m using SSL_CTX_set1_sigalgs_list to set my favorite signature algorithm. But there is more algorithm listed on client hello message than I desired. I defined a list #define TLS_PREFER_SIGNATURE"rsa_pss_rsae_sha256:" \ "rsa_pss_rsae_sha384:" \ "rsa_pss_rsae_sha512:" \ "rsa_pss_pss_sha256:" \ "rsa_pss_pss_sha384:" \ "rsa_pss_pss_sha512:" \ "ecdsa_secp256r1_sha256:" \ "ecdsa_secp384r1_sha384:" \ "ecdsa_secp521r1_sha512:" \ "rsa_pkcs1_sha256:" \ "rsa_pkcs1_sha384:" \ "rsa_pkcs1_sha5256" \ Then, use SSL_CTX_set1_sigalgs_list(pCtx, TLS_PREFER_SIGNATURE ) to customize signature algorithm. But in client hello, the signature algorithm has more than I listed. Signature Hash Algorithms (23 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Algorithm: ed25519 (0x0807) Signature Algorithm: ed448 (0x0808) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Algorithm: SHA224 RSA (0x0301) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Algorithm: SHA224 DSA (0x0302) Signature Algorithm: SHA1 DSA (0x0202) Signature Algorithm: SHA256 DSA (0x0402) Signature Algorithm: SHA384 DSA (0x0502) Signature Algorithm: SHA512 DSA (0x0602) Do I make any mistake ? How do i remove SHA+DSA, and others? Thanks -- Sincerely, Jared
Re: SSL_CTX_set1_curves to specify curves in Client Hello Supported Group Extension, not working
Hi, Am Dienstag, 26. November 2019, 09:11:15 CET schrieb Rohit Kaushal: > //enhancement, not working > > if(SSL_CTX_set1_curves(myCtx, "P-521:P-384:P-256", 3)) != 1)) > > return; > > > > The API returns 0 (suggesting no error), but pcap shows no change, i.e. > still shows the std. 13 curves. According to [1] SSL_CTX_set1_curves() returns 1 for success, 0 for failure. [1] https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set1_curves.html -- Kind regards Jan
Re: SSL_CTX_set1_curves to specify curves in Client Hello Supported Group Extension, not working
Hi, Need to use *SSL_CTX_set1_curves_list()*, for ECC curves configuration using string. SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256") Regards, R Ashok On Tue, Nov 26, 2019 at 1:42 PM Rohit Kaushal wrote: > Hi, > > I would like to ask if anyone here has actually been able to trim the EC > Supported Groups in the Client Hello with a TLS-ECDHE cipher using the APIs > described in the OpenSSL v1.0.2 manpage for SSL_CTX_set1_curves() > <https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set1_curves.html> > > > > My shared objects are built using OpenSSL v1.0.2t with FIPS Object Module > v2.0.5 . The TLS handshake pcap has always shown myCipher ( > "ECDHE-RSA-AES128-GCM-SHA256") in the Client Hello correctly, accompanied > with 13 curves in the Supported Group Extension. However, enhancing SSL_CTX > myCtx to restrict the curves to just 3 (P-521:P384:P256) still show the > same 13 curves as in the pcap. The man page doesn't suggest nor do i see > any reason why FIPS should prevent this from working. > > > //existing working code > > if((myCtx = SSL_CTX_new(SSL_METHOD *)TLSv1_2_method()) == NULL) > > return; > > if((SSL_CTX_set_cipher_list(myCtx, myCipher) != 1)) > > return; > > > > //enhancement, not working > > if(SSL_CTX_set1_curves(myCtx, "P-521:P-384:P-256", 3)) != 1)) > > return; > > > > The API returns 0 (suggesting no error), but pcap shows no change, i.e. > still shows the std. 13 curves. > > > > Trying a code snippet involving SSL_CONF_cmd(myConfCtx, "-named-curve", > "P-256") suggested in this link > <https://superuser.com/questions/912311/how-to-force-a-server-to-use-a-specific-elliptic-curve-at-the-beginning-of-the-h> > , > available prior to SSL_CTX_set1_curves() introduction in v1.0.2, didn’t > help either. > > > Thank you for any guidance you can provide. > > Rohit >
SSL_CTX_set1_curves to specify curves in Client Hello Supported Group Extension, not working
Hi, I would like to ask if anyone here has actually been able to trim the EC Supported Groups in the Client Hello with a TLS-ECDHE cipher using the APIs described in the OpenSSL v1.0.2 manpage for SSL_CTX_set1_curves() <https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set1_curves.html> My shared objects are built using OpenSSL v1.0.2t with FIPS Object Module v2.0.5 . The TLS handshake pcap has always shown myCipher ( "ECDHE-RSA-AES128-GCM-SHA256") in the Client Hello correctly, accompanied with 13 curves in the Supported Group Extension. However, enhancing SSL_CTX myCtx to restrict the curves to just 3 (P-521:P384:P256) still show the same 13 curves as in the pcap. The man page doesn't suggest nor do i see any reason why FIPS should prevent this from working. //existing working code if((myCtx = SSL_CTX_new(SSL_METHOD *)TLSv1_2_method()) == NULL) return; if((SSL_CTX_set_cipher_list(myCtx, myCipher) != 1)) return; //enhancement, not working if(SSL_CTX_set1_curves(myCtx, "P-521:P-384:P-256", 3)) != 1)) return; The API returns 0 (suggesting no error), but pcap shows no change, i.e. still shows the std. 13 curves. Trying a code snippet involving SSL_CONF_cmd(myConfCtx, "-named-curve", "P-256") suggested in this link <https://superuser.com/questions/912311/how-to-force-a-server-to-use-a-specific-elliptic-curve-at-the-beginning-of-the-h> , available prior to SSL_CTX_set1_curves() introduction in v1.0.2, didn’t help either. Thank you for any guidance you can provide. Rohit
Re: How do I turn off EC point formats from showing up in TLS 1.3 client hello?
On 15/11/2019 22:03, Phil Neumiller wrote: > > TLS 1.3 doesn't use EC point formats right? I don't know why they are in my > TLS 1.3 client hello. No, its not used in TLSv1.3 but is used in TLSv1.2 or below. A ClientHello is sent before version negotiation takes place so you don't know what version will eventually be selected. Therefore, if EC is enabled, this extension is always added regardless. A possible improvement would be for OpenSSL to detect whether TLSv1.3 is the only enabled protocol version on the client and disable it in those circumstances. But it doesn't currently check this. Currently the only way to disable this extension is to disable EC. However that means (assuming you are using 1.1.1 instead of master) that TLSv1.3 will not work since EC is required for the 1.1.1 TLSv1.3 support. In master that isn't the case so I guess it might be possible there but I've not tried it. Matt
How do I turn off EC point formats from showing up in TLS 1.3 client hello?
TLS 1.3 doesn't use EC point formats right? I don't know why they are in my TLS 1.3 client hello. Extension: ec_point_formats (len=4) Type: ec_point_formats (11) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) EC point format: uncompressed (0) EC point format: ansiX962_compressed_prime (1) EC point format: ansiX962_compressed_char2 (2) There is a flag OPENSSL_NO_EC do I need to set that somewhere in config or make? Is there an API call do disable these? There is a get function SSL_get0_ec_point_formats() but no set. Thanks, Phil - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
On Tuesday, 12 November 2019 21:22:51 CET, Benjamin Kaduk via openssl-users wrote: On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote: Thanks for all the useful device. I was able to get the server to accept this client hello message. If you're willing/able to share, it can be useful for us to know what products are buggy in that they don't implement extensions in a proper, extensible, manner and need to have the ClientHello extensions adjusted like this. If we have a list of "likely suspects" it can make diagnosing future connection issues easier. contributing a fingerprint to https://github.com/WestpointLtd/tls_prober would also be really welcome, for the same reasons -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Re: Removing Extensions from Client Hello Header
On Tue, Nov 12, 2019 at 03:08:19PM -0700, Phil Neumiller wrote:
> I find the comment below about TLS 1.3 troubling.
[...]
> */*
> * TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test
> it
> * for TLSv1.2 for now until we add a new API.
> */*
> SSL_CTX_set_max_proto_version(cctx, TLS1_2_VERSION);
>
> if (testctx) {
> int ret;
>
> if (curr->list != NULL)
> ret = SSL_CTX_set1_sigalgs(cctx, curr->list, curr->listlen);
> else
> ret = SSL_CTX_set1_sigalgs_list(cctx, curr->liststr);
I don't.
>From SSL_CTX_set1_sigalgs.pod:
% The TLS 1.3 signature scheme names (such as "rsa_pss_pss_sha256") can also
% be used with the B<_list> forms of the API.
The TLS 1.3 schemes don't decompose into SIG+HASH, so this is just a constraint
inherent to the old API, not a bug.
-Ben
Re: Removing Extensions from Client Hello Header
I find the comment below about TLS 1.3 troubling.
static int test_set_sigalgs(int idx)
{
SSL_CTX *cctx = NULL, *sctx = NULL;
SSL *clientssl = NULL, *serverssl = NULL;
int testresult = 0;
const sigalgs_list *curr;
int testctx;
/* Should never happen */
if (!TEST_size_t_le((size_t)idx, OSSL_NELEM(testsigalgs) * 2))
return 0;
testctx = ((size_t)idx < OSSL_NELEM(testsigalgs));
curr = testctx ? [idx]
: [idx - OSSL_NELEM(testsigalgs)];
if (!TEST_true(create_ssl_ctx_pair(TLS_server_method(),
TLS_client_method(),
TLS1_VERSION, 0,
, , cert, privkey)))
return 0;
*/*
* TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test
it
* for TLSv1.2 for now until we add a new API.
*/*
SSL_CTX_set_max_proto_version(cctx, TLS1_2_VERSION);
if (testctx) {
int ret;
if (curr->list != NULL)
ret = SSL_CTX_set1_sigalgs(cctx, curr->list, curr->listlen);
else
ret = SSL_CTX_set1_sigalgs_list(cctx, curr->liststr);
if (!ret) {
-
Phillip Neumiller
Platform Engineering
Directstream, LLC
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote: > Thanks for all the useful device. I was able to get the server to accept > this client hello message. If you're willing/able to share, it can be useful for us to know what products are buggy in that they don't implement extensions in a proper, extensible, manner and need to have the ClientHello extensions adjusted like this. If we have a list of "likely suspects" it can make diagnosing future connection issues easier. Thanks, Ben
Re: Removing Extensions from Client Hello Header
Thanks for all the useful device. I was able to get the server to accept this client hello message. TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 257 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 253 Version: TLS 1.2 (0x0303) Random: 00010002000400090012… Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 210 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: x25519 (0x001d) Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 009201240249049209241249… Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: heartbeat (len=1) Type: heartbeat (15) Length: 1 Mode: Peer not allowed to send requests (2) Extension: pre_shared_key (len=130) Type: pre_shared_key (41) Length: 130 Pre-Shared Key extension Identities Length: 28 PSK Identity (length: 8) Identity Length: 8 Identity: 924900012492 Obfuscated Ticket Age: 0 PSK Identity (length: 8) Identity Length: 8 Identity: Obfuscated Ticket Age: 0 PSK Binders length: 98 PSK Binders So just one signature algorithm. Now the response I got from the OpenSSL TLS server is this server hello. TLSv1.3 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 90 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 86 Version: TLS 1.2 (0x0303) Random: 7f9801c0f94da77d9d2c100cba7ff587bec25bca39defd81… Session ID Length: 0 Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Compression Method: null (0) Extensions Length: 46 Extension: supported_versions (len=2) Type: supported_versions (43) Length: 2 Supported Version: TLS 1.3 (0x0304) Extension: key_share (len=36) Type: key_share (51) Length: 36 Key Share extension Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: ab6c1e5e5a83cdeee70487c509bd0810668a32fa2402f7d7… Now to try the actual hardware At least openssl TLS 1.3 is OK with just 1 signature algorithm for my special case of external out of band PSK. - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
On 11/11/2019 20:51, Phil Neumiller wrote: > Extension: ec_point_formats (len=4) > Type: ec_point_formats (11) > Length: 4 > EC point formats Length: 3 > Elliptic curves point formats (3) > EC point format: uncompressed (0) > EC point format: ansiX962_compressed_prime (1) > EC point format: ansiX962_compressed_char2 (2) > Extension: session_ticket (len=0) > Type: session_ticket (35) > Length: 0 > Data (0 bytes) > Extension: encrypt_then_mac (len=0) > Type: encrypt_then_mac (22) > Length: 0 > Extension: extended_master_secret (len=0) > Type: extended_master_secret (23) > Length: 0 You don't need these four for TLSv1.3 SSL_OP_NO_TICKET will turn off session_ticket. SSL_OP_NO_ENCRYPT_THEN_MAC will turn off encrypt_then_mac. SSL_OP_NO_EXTENDED_MASTER_SECRET will turn off extended_master_secret. Don't switch off encrypt-then-mac or extended-master-secret unless you *really* need to. They don't do anything in TLSv1.3 but if you ever ended up negotiating TLSv1.2 by mistake for some reason then switching these things off has security consequences. I think the only way to get rid of ec_point_formats would be to disable EC from being used completely. But, you need EC to be enabled in order use TLSv1.3 (at least in 1.1.1 - in master its different). So I don't think you can get rid of this extension. But I'd really look at why your hardware is failing when these extensions are present. Is it intolerant of one particular extension? If so I'd just disable that one. Matt
Re: Removing Extensions from Client Hello Header
On 11/11/2019 21:09, Phil Neumiller wrote: > The hardware wants to see a client hello like the following: By this do you imply that if you give it additional extensions it fails? That is a highly non-compliant implementation!! Matt
Re: Removing Extensions from Client Hello Header
On 11/11/2019 22:12, Michael Wojcik wrote: > -Original Message- >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Phil Neumiller >> Sent: Monday, November 11, 2019 15:57 >> >> Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); > > That's just a verbose way of saying SSL_CTX_set_options(ctx, 0). > > Perhaps you meant SSL_CTX_set_options(ctx, ~SSL_OP_ALL)? I certainly wouldn't > recommend that - it would enable a host of options which aren't included in > SSL_OP_ALL, and which you very likely shouldn't be enabling. (And also some > you perhaps should, such as SSL_OP_SINGLE_ECDH_USE, though I don't remember > offhand if that affects TLSv1.3.) There is no need to enable SSL_OP_SINGLE_ECDH_USE. In fact that option does nothing: /* Removed from OpenSSL 1.1.0. Was 0x0008L */ # define SSL_OP_SINGLE_ECDH_USE 0x0 Matt
RE: Removing Extensions from Client Hello Header
-Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Phil Neumiller > Sent: Monday, November 11, 2019 15:57 > > Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); That's just a verbose way of saying SSL_CTX_set_options(ctx, 0). Perhaps you meant SSL_CTX_set_options(ctx, ~SSL_OP_ALL)? I certainly wouldn't recommend that - it would enable a host of options which aren't included in SSL_OP_ALL, and which you very likely shouldn't be enabling. (And also some you perhaps should, such as SSL_OP_SINGLE_ECDH_USE, though I don't remember offhand if that affects TLSv1.3.) SSL_OP_ALL is defined as "various bug workarounds that should be rather harmless". I don't believe its use is appropriate here. As with any implementation of any protocol, there are limits to OpenSSL's ability to deal with noncompliant peers. This may be a case where you have to customize your OpenSSL build in order to get it to connect to your apparently-non-compliant server. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: Removing Extensions from Client Hello Header
The hardware wants to see a client hello like the following: Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 253 Version: TLS 1.2 (0x0303) Random: 00010002000400090012… GMT Unix Time: Dec 31, 1969 17:00:00.0 MST Random Bytes: 000100020004000900120024… Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 210 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: x25519 (0x001d) Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 009201240249049209241249… Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: heartbeat (len=1) Type: heartbeat (15) Length: 1 Mode: Peer not allowed to send requests (2) Extension: pre_shared_key (len=130) Type: pre_shared_key (41) Length: 130 Pre-Shared Key extension Identities Length: 28 PSK Identity (length: 8) Identity Length: 8 Identity: 924900012492 Obfuscated Ticket Age: 0 PSK Identity (length: 8) Identity Length: 8 Identity: Obfuscated Ticket Age: 0 PSK Binders length: 98 PSK Binders - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
By doing the following in my code: I was able to get the Client Hello Extensions down to. Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 365 Version: TLS 1.2 (0x0303) Random: 19ff8a9231e83985887f5e45f2c9b243f0ccaa955beb1f03… Session ID Length: 32 Session ID: ebcab15bff6e5abfc14588298b45a56f74963eda97645992… Cipher Suites Length: 8 Cipher Suites (4 suites) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 284 Extension: ec_point_formats (len=4) Type: ec_point_formats (11) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) EC point format: uncompressed (0) EC point format: ansiX962_compressed_prime (1) EC point format: ansiX962_compressed_char2 (2) Extension: supported_groups (len=8) Type: supported_groups (10) Length: 8 Supported Groups List Length: 6 Supported Groups (3 groups) Supported Group: secp521r1 (0x0019) Supported Group: secp384r1 (0x0018) Supported Group: secp256r1 (0x0017) Extension: session_ticket (len=0) Type: session_ticket (35) Length: 0 Data (0 bytes) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: signature_algorithms (len=30) Type: signature_algorithms (13) Length: 30 Signature Hash Algorithms Length: 28 Signature Hash Algorithms (14 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ed25519 (0x0807) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (7) Signature Algorithm: ed448 (0x0808) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (8) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (9) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (10) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (11) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=139) Type: key_share (51) Length: 139 Key Share
Re: Removing Extensions from Client Hello Header
On 11/11/2019 19:43, Benjamin Kaduk via openssl-users wrote: > On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote: >> I am speaking TLS 1.3 with openssl to a hardware device that I can't change. >> I need the client hello header to only support certain extensions, yet I Any compliant implementation should ignore extensions it doesn't understand so why do you need to do this? >> see no way in the SSL API to remove the default extensions in the TLS 1.3 >> client hello. Can I clear them all and just add the ones I want? What am I >> missing? Do I have to modify the SSL code to do this? It seems like there >> should be an orthodox way to do this. > > You have to disable them one by one; see SSL_CTX_set_options(3) and (e.g.) > SSL_OP_NO_EXTENDED_MASTER_SECRET. Only certain headers can be disabled in this way. Many of the extensions present in a TLSv1.3 ClientHello are necessary for proper functioning of the protocol. Which extensions did you actually want to disable? Matt
Re: Removing Extensions from Client Hello Header
On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote: > I am speaking TLS 1.3 with openssl to a hardware device that I can't change. > I need the client hello header to only support certain extensions, yet I > see no way in the SSL API to remove the default extensions in the TLS 1.3 > client hello. Can I clear them all and just add the ones I want? What am I > missing? Do I have to modify the SSL code to do this? It seems like there > should be an orthodox way to do this. You have to disable them one by one; see SSL_CTX_set_options(3) and (e.g.) SSL_OP_NO_EXTENDED_MASTER_SECRET. -Ben
Removing Extensions from Client Hello Header
I am speaking TLS 1.3 with openssl to a hardware device that I can't change. I need the client hello header to only support certain extensions, yet I see no way in the SSL API to remove the default extensions in the TLS 1.3 client hello. Can I clear them all and just add the ones I want? What am I missing? Do I have to modify the SSL code to do this? It seems like there should be an orthodox way to do this. - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: SSL_connect:error in SSLv3/TLS write client hello → write:errno=0
Hi all, The problem was an expired self-generated CA certificate. Now everything works fine. Br, Harri On 12.04.2019 20:20, Harri T. wrote: Hi! I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in SSLv3/TLS write client hello → write:errno=0" mean? Harri root@ldap2:~# echo | openssl s_client -connect ldap2.mydomain.com:389 -showcerts -state -CAfile /etc/ssl/certs/ldap2_cacert.pem CONNECTED(0003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1555084061 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
SSL_connect:error in SSLv3/TLS write client hello → write:errno=0
Hi! I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in SSLv3/TLS write client hello → write:errno=0" mean? Harri root@ldap2:~# echo | openssl s_client -connect ldap2.mydomain.com:389 -showcerts -state -CAfile /etc/ssl/certs/ldap2_cacert.pem CONNECTED(0003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1555084061 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
[openssl-users] Setting Signature algorithm for Client Hello in openssl.cnf
Hi All, I am looking for an option in "openssl.cnf" file to control the signature algorithms supported by an OpenSSL based TLS client application which it lists in the "Client Hello" message and also the signature algorithm used for signing the Client "CertificateVerify" message sent to the server for proof of possession of the client private key Is there an option to set this in openssl.cnf file?. I searched the man pages, but did not see a corresponding option. What i got so far is - ssl_conf = ssl_sect [ssl_sect] client = client_secion [client_section] ClientSignatureAlgorithms=RSA+SHA256 --- Is this supported in conf file? Can somebody help me with this? Thanks. -- Regards, Sreekanth -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Regarding to disable some signature algorithm in client hello message
I tried to modify " tls12_sigalgs" list under t1_lib.c in OpenSSL 1.0.2x version to restrict a bunch of signature algorithms from being proposed during Client hello message. That did work. Thanks. Srivalli On 6/19/18, 5:36 AM, "openssl-users on behalf of murugesh pitchaiah" wrote: Hi, SSL_CTX_set1_client_sigalgs_list - is the correct method for this purpose. Just try for checking return value of this function. On failure it returns 0. Also try SSL_CTX_set1_client_sigalgs_list (ctx, "RSA+SHA256"); Thanks, Murugesh P. On 6/19/18, Devang Kubavat wrote: > Hi, > > I want to disable the SHA1 hash algorithm in Extension: signature algorithm > client hello message. > > [cid:image003.jpg@01D407C3.1A227530] > > I have used > /* the signature algorithms list */ > const char signAlgo[] = "RSA+SHA256"; > (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); > > But, still client is setting all algorithms. Is there any other way to set > signature algorithm to SSL_CTX or SSL ? > > > Best Regards, > Devang > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Regarding to disable some signature algorithm in client hello message
On 19/06/18 07:16, Devang Kubavat wrote: > Hi, > > > > I want to disable the SHA1 hash algorithm in Extension: signature > algorithm client hello message. > > > > I have used > > /* the signature algorithms list */ > > constcharsignAlgo[] = "RSA+SHA256"; > > (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); > > > > But, still client is setting all algorithms. Is there any other way to > set signature algorithm to SSL_CTX or SSL ? The function "SSL_CTX_set1_client_sigalgs_list()" is for setting signature algorithms related to *client authentication*. This is not the same as the sig algs sent in the ClientHello. For that you need to use SSL_CTX_set1_sigalgs_list(). Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Regarding to disable some signature algorithm in client hello message
Hi, SSL_CTX_set1_client_sigalgs_list - is the correct method for this purpose. Just try for checking return value of this function. On failure it returns 0. Also try SSL_CTX_set1_client_sigalgs_list (ctx, "RSA+SHA256"); Thanks, Murugesh P. On 6/19/18, Devang Kubavat wrote: > Hi, > > I want to disable the SHA1 hash algorithm in Extension: signature algorithm > client hello message. > > [cid:image003.jpg@01D407C3.1A227530] > > I have used > /* the signature algorithms list */ > const char signAlgo[] = "RSA+SHA256"; > (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); > > But, still client is setting all algorithms. Is there any other way to set > signature algorithm to SSL_CTX or SSL ? > > > Best Regards, > Devang > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Regarding to disable some signature algorithm in client hello message
Hi, I want to disable the SHA1 hash algorithm in Extension: signature algorithm client hello message. [cid:image003.jpg@01D407C3.1A227530] I have used /* the signature algorithms list */ const char signAlgo[] = "RSA+SHA256"; (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); But, still client is setting all algorithms. Is there any other way to set signature algorithm to SSL_CTX or SSL ? Best Regards, Devang -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] TLS 1.2 Client hello missing SessionTicket
Hi Folks, I'm working on an issue where something seems to be going wrong with our internal state after a while, and one of our sessions will have suddenly lost its SessionTicket during the Client Hello. To debug the issue, I'm wondering if someone can point me to the right internal variable in openssl that I might want to put a data breakpoint on so I can see the call stack that led to the problem. A wireshark trace shows that the SessionTicket length is zero when the problem occurs. Thanks for any suggestions, Mike -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] parse tlsext error in response to client hello
Many thanks! I'll chase down the vendor. The device in question is a Canon imagerunner MFP in case anyone was wondering. --OLW -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Monday, January 25, 2016 6:42 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] parse tlsext error in response to client hello On 25/01/16 20:02, Wieck, Owen wrote: > Dear all -- > > Trying to debug a failing TLS negotiation. Is the following (possibly > erroneous) "supported point formats extension" the cause of openssl's "parse > tlsext" error? Yes. I copied your record below and pushed it through OpenSSL to recreate the error. It is indeed failing on the parsing of the supported point formats extension for precisely the reason you have specified. OpenSSL automatically rejects a zero length point formats extension. Matt > > 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == > the length (1 byte), and 00 == a zero-length ec point formats list. > > The example in RFC 4492 (section 5.1.2) is: > > A client that can parse only the uncompressed point format (value 0) >includes an extension consisting of the following octets; note that >the first two octets indicate the extension type (Supported Point >Formats Extension): > > 00 0B 00 02 01 00 > > And further, section 5.1 of the same RFC explicitly states "if the Supported > Point Formats Extension is indeed sent, it MUST contain the value 0 > (uncompressed) as one of the items in the list of point formats." > > For reference, here is the complete "SSL record" of the client hello taken > from a packet capture: > > 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 > 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 > 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f > 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 > 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 > 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 > 0060 00 > > Many Thanks! > > --OLW > > P.S.: Apologies for the enormous footer that gets tacked on below here. > -- > -- > -- This e-mail and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this e-mail in error > please notify the sender immediately and delete this e-mail from your system. > Please note that any views or opinions presented in this e-mail are > solely those of the author and do not necessarily represent those of > Ricardo (save for reports and other documentation formally approved > and signed for release to the intended recipient). Only Ricardo's > authorized representatives may enter into legally binding obligations on > behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and > other telecommunications systems. By replying to this e-mail you give consent > to such monitoring. The recipient should check e-mail and any attachments for > the presence of viruses. Ricardo accepts no liability for any damage caused > by any virus transmitted by this e-mail. > "Ricardo" means Ricardo Inc. and its affiliated companies. > --'. > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give co
[openssl-users] parse tlsext error in response to client hello
Dear all -- Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. The example in RFC 4492 (section 5.1.2) is: A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension): 00 0B 00 02 01 00 And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." For reference, here is the complete "SSL record" of the client hello taken from a packet capture: 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 0060 00 Many Thanks! --OLW P.S.: Apologies for the enormous footer that gets tacked on below here. -- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --'. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] parse tlsext error in response to client hello
Dear all -- Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. The example in RFC 4492 (section 5.1.2) is: A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension): 00 0B 00 02 01 00 And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." For reference, here is the complete "SSL record" of the client hello taken from a packet capture: 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 0060 00 Many Thanks! --OLW -- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --'. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] parse tlsext error in response to client hello
On 25/01/16 20:02, Wieck, Owen wrote: > Dear all -- > > Trying to debug a failing TLS negotiation. Is the following (possibly > erroneous) "supported point formats extension" the cause of openssl's "parse > tlsext" error? Yes. I copied your record below and pushed it through OpenSSL to recreate the error. It is indeed failing on the parsing of the supported point formats extension for precisely the reason you have specified. OpenSSL automatically rejects a zero length point formats extension. Matt > > 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == > the length (1 byte), and 00 == a zero-length ec point formats list. > > The example in RFC 4492 (section 5.1.2) is: > > A client that can parse only the uncompressed point format (value 0) >includes an extension consisting of the following octets; note that >the first two octets indicate the extension type (Supported Point >Formats Extension): > > 00 0B 00 02 01 00 > > And further, section 5.1 of the same RFC explicitly states "if the Supported > Point Formats Extension is indeed sent, it MUST contain the value 0 > (uncompressed) as one of the items in the list of point formats." > > For reference, here is the complete "SSL record" of the client hello taken > from a packet capture: > > 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 > 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 > 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f > 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 > 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 > 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 > 0060 00 > > Many Thanks! > > --OLW > > P.S.: Apologies for the enormous footer that gets tacked on below here. > -- > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are > addressed. If you have received this e-mail in error please notify the sender > immediately and delete this e-mail from your system. > Please note that any views or opinions presented in this e-mail are solely > those of the author and do not necessarily represent those > of Ricardo (save for reports and other documentation formally approved and > signed for release to the intended recipient). Only Ricardo's > authorized representatives may enter into legally binding obligations on > behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and > other telecommunications systems. By replying to this e-mail you give consent > to such monitoring. The recipient should check e-mail and > any attachments for the presence of viruses. Ricardo accepts no liability for > any damage caused by any virus transmitted by this e-mail. > "Ricardo" means Ricardo Inc. and its affiliated companies. > --'. > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl not sending "client hello" request
And Kurt... you were right. When setting a pixelserver to do DNS-level ad-blocking, I set up a loopback interfaces 192.0.0.2 (It should have been 127.0.0.2) So... yes as github is 192.30... everything was directed to loopback iface, and my apache server was the one answering :S Thank you for making me think! Felix On Wednesday, 30 December 2015 14:08:19 CET Kurt Roeckx wrote: > On Tue, Dec 29, 2015 at 08:35:49PM +0100, Felix Rubio Dalmau wrote: > > Hi all, > > > > I have been searching for some time for a solution and I can not > > manage to > > solve my problem. I have a computer that can not connect to some sites, > > e.g. > > github, by using openssl. I am running a debian testing with all the > > updates > > available as of today, and libssl used is v1.0.2. If I execute: > > > > > openssl s_client -connect github.com:443 > > The trace file you attached, which claims to go github.com:443, > did send a Client Hello. However the reply is a plain text > "400 Bad Request". It looks like you connected to port 80 and not > 443 for some reason. I suspect something is broken in your network. > > > Kurt > > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl not sending "client hello" request
On Tue, Dec 29, 2015 at 08:35:49PM +0100, Felix Rubio Dalmau wrote: > Hi all, > > I have been searching for some time for a solution and I can not > manage to > solve my problem. I have a computer that can not connect to some sites, e.g. > github, by using openssl. I am running a debian testing with all the updates > available as of today, and libssl used is v1.0.2. If I execute: > > > openssl s_client -connect github.com:443 The trace file you attached, which claims to go github.com:443, did send a Client Hello. However the reply is a plain text "400 Bad Request". It looks like you connected to port 80 and not 443 for some reason. I suspect something is broken in your network. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl not sending "client hello" request
Hi all, I have been searching for some time for a solution and I can not manage to solve my problem. I have a computer that can not connect to some sites, e.g. github, by using openssl. I am running a debian testing with all the updates available as of today, and libssl used is v1.0.2. If I execute: > openssl s_client -connect github.com:443 The only answer I get is: > CONNECTED(0003) > 140058172421776:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:794: --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 315 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > > SSL-Session: > Protocol : TLSv1.2 > Cipher: > Session-ID: > Session-ID-ctx: > Master-Key: > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1451415453 > Timeout : 300 (sec) > Verify return code: 0 (ok) > > --- I have created a network namespace and executed the program inside while sniffing the traffic with tcpdump (See attached file). If I execute ***the same*** openssl binary on my arch linux, the program works flawlessly. If I obtain also the traffic on the arch, I see a difference: in my debian there is no clienthello sent to the server, whereas in arch linux it is. I would consider, under these circumstances, that is an environment problem in my debian. Therefore I have executed the same command on a completely fresh bash, without any strange environment vars, obtaining the same result. Then I thought it could be related to any configuration file, but... I have not been able to find any :S Can somebody give any hint? I would really appreciate it. thank you! Felix not_working.cap Description: application/vnd.tcpdump.pcap ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl not sending "client hello" request
Hi all, I have been searching for some time for a solution and I can not manage to solve my problem. I have a computer that can not connect to some sites, e.g. github, by using openssl. I am running a debian testing with all the updates available as of today, and libssl used is v1.0.2. If I execute: > openssl s_client -connect github.com:443 The only answer I get is: > CONNECTED(0003) > 140058172421776:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:794: --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 315 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > > SSL-Session: > Protocol : TLSv1.2 > Cipher: > Session-ID: > Session-ID-ctx: > Master-Key: > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1451415453 > Timeout : 300 (sec) > Verify return code: 0 (ok) > > --- I have created a network namespace and executed the program inside while sniffing the traffic with tcpdump (See attached file). If I execute ***the same*** openssl binary on my arch linux, the program works flawlessly. If I obtain also the traffic on the arch, I see a difference: in my debian there is no clienthello sent to the server, whereas in arch linux it is. I would consider, under these circumstances, that is an environment problem in my debian. Therefore I have executed the same command on a completely fresh bash, without any strange environment vars, obtaining the same result. Then I thought it could be related to any configuration file, but... I have not been able to find any :S Can somebody give any hint? I would really appreciate it. thank you! Felix not_working.cap Description: application/vnd.tcpdump.pcap ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
client hello difference 1.0.1e vs 1.0.1f
Hi,
Is it possible to make s_client give more detail about the client
hello it sends. A break down covering the RFC structure would be
useful.
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites2..2^16-1;
CompressionMethod compression_methods1..2^8-1;
} ClientHello;
I'm trying to work out what is different between these two connections
(and why one works but the other doesn't):
$ ~/Downloads/openssl-1.0.1f/apps/openssl s_client -connect
yum.dev.bbc.co.uk:443 -cert /home/stan/Downloads/hillt08.pem -CAfile
/home/stan/Downloads/ca.pem -debug -state
WARNING: can't open config file:
/home/stan/Downloads/openssl-1.0.1f/prefix/openssl.cnf
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0x1d71d10 [0x1d71d90] (319 bytes = 319 (0x13F))
- 16 03 01 01 3a 01 00 01-36 03 03 70 e7 e7 64 c8 :...6..p..d.
0010 - 4d 6e 3e 08 a9 f9 98 15-6d c2 64 34 6a 84 c3 f7 Mn.m.d4j...
0020 - 7d 8a 1b b5 9e ab 79 98-7a 37 ec 00 00 a0 c0 30 }.y.z7.0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.#
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 00 07 /...A..
00b0 - c0 11 c0 07 c0 0c c0 02-00 05 00 04 00 15 00 12
00c0 - 00 09 00 14 00 11 00 08-00 06 00 03 00 ff 01 00
00d0 - 00 6d 00 0b 00 04 03 00-01 02 00 0a 00 34 00 32 .m...4.2
00e0 - 00 0e 00 0d 00 19 00 0b-00 0c 00 18 00 09 00 0a
00f0 - 00 16 00 17 00 08 00 06-00 07 00 14 00 15 00 04
0100 - 00 05 00 12 00 13 00 01-00 02 00 03 00 0f 00 10
0110 - 00 11 00 23 00 00 00 0d-00 20 00 1e 06 01 06 02 ...#. ..
0120 - 06 03 05 01 05 02 05 03-04 01 04 02 04 03 03 01
0130 - 03 02 03 03 02 01 02 02-02 03 00 0f 00 01 01 ...
SSL_connect:SSLv2/v3 write client hello A
read from 0x1d71d10 [0x1d772f0] (7 bytes = 7 (0x7))
- 15 03 03 00 02 02 28 ..(
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
140550067680928:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure:s23_clnt.c:762:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 319 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
$ ~/Downloads/openssl-1.0.1e/apps/openssl s_client -connect
yum.dev.bbc.co.uk:443 -cert /home/stan/Downloads/hillt08.pem -CAfile
/home/stan/Downloads/ca.pem -debug -state
WARNING: can't open config file:
/home/stan/Downloads/openssl-1.0.1e/prefix/openssl.cnf
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0xfa9cf0 [0xfa9d70] (321 bytes = 321 (0x141))
- 16 03 01 01 3c 01 00 01-38 03 03 54 63 25 81 54 ...8..Tc%.T
0010 - 37 70 1d 7e 32 ad a3 ab-6a 54 2c 18 96 6f f5 59 7p.~2...jT,..o.Y
0020 - f6 49 e1 c7 72 ab a5 06-51 61 29 00 00 a0 c0 30 .I..r...Qa)0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.#
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 00 07 /...A..
00b0 - c0 11 c0 07 c0 0c c0 02-00 05 00 04 00 15 00 12
00c0 - 00 09 00 14 00 11 00 08-00 06 00 03 00 ff 01 00
00d0 - 00 6f 00 0b 00 04 03 00-01 02 00 0a 00 34 00 32 .o...4.2
00e0 - 00 0e 00 0d 00 19 00 0b-00 0c 00 18 00 09 00 0a
00f0 - 00 16 00 17 00 08 00 06-00 07 00 14 00 15 00 04
0100 - 00 05 00 12 00 13 00 01-00 02 00 03 00 0f 00 10
0110 - 00 11 00 23 00 00 00 0d-00 22 00 20 06 01 06 02 ...#..
0120 - 06 03 05 01 05 02 05 03-04 01 04 02 04 03 03 01
0130 - 03 02 03 03 02 01 02 02-02 03 01 01 00 0f 00 01
0140 - 01.
SSL_connect:SSLv2/v3 write client hello A
read from 0xfa9cf0 [0xfaf2d0] (7 bytes = 7 (0x7))
- 16 03 03 00 51 02
RE: client hello difference 1.0.1e vs 1.0.1f
Took me a while to see, but the difference is in the last line of the client
hello. Your working example has MD5+RSA listed as a TLS 1.2 signature pair
whereas first doesn't.
0302 SHA-224 DSA
0303 SHA-224 ECDSA
0201 SHA-1 RSA
0202 SHA-1 DSA
0203 SHA-1 ECDSA
000F TLS_DH_RSA_WITH_DES_CBC_SHA
0101 (missing from first example) MD5 RSA
0001 TLS_NULL_WITH_NULL_MD5
0130 - 03 02 03 03 02 01 02 02-02 03 00 0f 00 01 01 ...
0130 - 03 02 03 03 02 01 02 02-02 03 01 01 00 0f 00 01
0140 - 01.
The trailing 1 is compression.
Carl
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Tristan Hill [tris...@saticed.me.uk]
Sent: 12 November 2014 09:32
To: openssl-users@openssl.org
Subject: client hello difference 1.0.1e vs 1.0.1f
Hi,
Is it possible to make s_client give more detail about the client
hello it sends. A break down covering the RFC structure would be
useful.
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites2..2^16-1;
CompressionMethod compression_methods1..2^8-1;
} ClientHello;
I'm trying to work out what is different between these two connections
(and why one works but the other doesn't):
$ ~/Downloads/openssl-1.0.1f/apps/openssl s_client -connect
yum.dev.bbc.co.uk:443 -cert /home/stan/Downloads/hillt08.pem -CAfile
/home/stan/Downloads/ca.pem -debug -state
WARNING: can't open config file:
/home/stan/Downloads/openssl-1.0.1f/prefix/openssl.cnf
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0x1d71d10 [0x1d71d90] (319 bytes = 319 (0x13F))
- 16 03 01 01 3a 01 00 01-36 03 03 70 e7 e7 64 c8 :...6..p..d.
0010 - 4d 6e 3e 08 a9 f9 98 15-6d c2 64 34 6a 84 c3 f7 Mn.m.d4j...
0020 - 7d 8a 1b b5 9e ab 79 98-7a 37 ec 00 00 a0 c0 30 }.y.z7.0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.#
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 00 07 /...A..
00b0 - c0 11 c0 07 c0 0c c0 02-00 05 00 04 00 15 00 12
00c0 - 00 09 00 14 00 11 00 08-00 06 00 03 00 ff 01 00
00d0 - 00 6d 00 0b 00 04 03 00-01 02 00 0a 00 34 00 32 .m...4.2
00e0 - 00 0e 00 0d 00 19 00 0b-00 0c 00 18 00 09 00 0a
00f0 - 00 16 00 17 00 08 00 06-00 07 00 14 00 15 00 04
0100 - 00 05 00 12 00 13 00 01-00 02 00 03 00 0f 00 10
0110 - 00 11 00 23 00 00 00 0d-00 20 00 1e 06 01 06 02 ...#. ..
0120 - 06 03 05 01 05 02 05 03-04 01 04 02 04 03 03 01
0130 - 03 02 03 03 02 01 02 02-02 03 00 0f 00 01 01 ...
SSL_connect:SSLv2/v3 write client hello A
read from 0x1d71d10 [0x1d772f0] (7 bytes = 7 (0x7))
- 15 03 03 00 02 02 28 ..(
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
140550067680928:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure:s23_clnt.c:762:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 319 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
$ ~/Downloads/openssl-1.0.1e/apps/openssl s_client -connect
yum.dev.bbc.co.uk:443 -cert /home/stan/Downloads/hillt08.pem -CAfile
/home/stan/Downloads/ca.pem -debug -state
WARNING: can't open config file:
/home/stan/Downloads/openssl-1.0.1e/prefix/openssl.cnf
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0xfa9cf0 [0xfa9d70] (321 bytes = 321 (0x141))
- 16 03 01 01 3c 01 00 01-38 03 03 54 63 25 81 54 ...8..Tc%.T
0010 - 37 70 1d 7e 32 ad a3 ab-6a 54 2c 18 96 6f f5 59 7p.~2...jT,..o.Y
0020 - f6 49 e1 c7 72 ab a5 06-51 61 29 00 00 a0 c0 30 .I..r...Qa)0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.#
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00
Re: client hello difference 1.0.1e vs 1.0.1f
On Wed, Nov 12, 2014, Tristan Hill wrote:
Hi,
Is it possible to make s_client give more detail about the client
hello it sends. A break down covering the RFC structure would be
useful.
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites2..2^16-1;
CompressionMethod compression_methods1..2^8-1;
} ClientHello;
I'm trying to work out what is different between these two connections
(and why one works but the other doesn't):
It is but it's only supported in OpenSSL 1.0.2 and later. You compile OpenSSL
with enable-ssl-trace and use the -trace option to s_client/s_server.
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Parsing an SSL hello packet
On 28 Oct 2014, at 1:30 PM, Florian Weimer f...@deneb.enyo.de wrote: * Graham Leggett: I have a need to parse the first incoming hello packet on an incoming TLS connection and based on the presence (or absence) of the SNI header, choose to pass the connection through to another server. I think you'll need to work with BIOs to make a copy of the initial handshake messages and prevent the OpenSSL code from sending any data, install a server name callback (see SSL_CTX_callback_ctrl and SSL_CTRL_SET_TLSEXT_SERVERNAME_CB), and abort the connection from OpenSSL's point of view at that point. You then know the SNI value and can forward the stored handshake messages to the correct server. The callback is invoked fairly late, so OpenSSL needs to be able to parse the handshake messages. A separate Client Hello parser is not part of the OpenSSL public API. Is there a way to know whether the initial handshake has arrived fully? Should I just call SSL_read() over and over until the point at which it wants to write data, and go “initial handshake is done”? Regards, Graham — __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Parsing an SSL hello packet
* Graham Leggett: Is there a way to know whether the initial handshake has arrived fully? I think you can abort the handshake from within the server name callback with a suitable return value, so this does not really matter. You just have to make sure the alert is never sent to the client, and that you can feed all data processed by OpenSSL to the real server. Should I just call SSL_read() over and over until the point at which it wants to write data, and go “initial handshake is done”? This would work. Calling SSL_do_handshake() seems more explicit, though. To be honest, I'm not sure if it is a good idea to graft this in top of OpenSSL. On the other hand, it's likely that successful processing of Client Hellos needs some undocumented magic (to account for misbehaving clients), so it's not just a matter of reimplementing what's described in the TLS 1.2 RFC. (The wire format itself is pretty simple.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Parsing an SSL hello packet
Hi all, I have a need to parse the first incoming hello packet on an incoming TLS connection and based on the presence (or absence) of the SNI header, choose to pass the connection through to another server. What openssl functions should I be looking at to do this? Regards, Graham — __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Fwd: Hello, some dev question
--
alpha_one_x86 alpha_one_...@first-world.info
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department
---BeginMessage---
Hello,
I have some question:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
What part is global, what part need be do by connexion?
On that's:
https://github.com/alphaonex86/CatchChallenger/blob/master/tools/epoll-with-buffer/main.cpp
I have edited it to try do simple echo server.
The handshake work, but no the echo (don't read any thing).
I try do a sample how do epoll server with SSL support (not found on internet).
And remake this graphic, and comment the code to match with this graphic. And
into C++...
I need too maximum of performance (no client cert), non blocking ops.
Thanks for your help.
--
alpha_one_x86 alpha_one_...@first-world.info
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department
#include sys/epoll.h
#include errno.h
#include iostream
#include list
#include sys/socket.h
#include netdb.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include Client.h
#include Socket.h
#include Server.h
#include Epoll.h
#include Timer.h
#include TimerDisplayEventBySeconds.h
#define MAXEVENTS 512
#define MAXCLIENT 6000
SSL_CTX* InitServerCTX(void)
{
OpenSSL_add_all_algorithms(); /* load register all cryptos, etc. */
SSL_load_error_strings(); /* load all error messages */
const SSL_METHOD *method = TLSv1_2_server_method(); /* create new server-method instance */
SSL_CTX *ctx = SSL_CTX_new(method); /* create new context from method */
if(ctx == NULL)
{
ERR_print_errors_fp(stderr);
abort();
}
return ctx;
}
void LoadCertificates(SSL_CTX* ctx, const char* CertFile, const char* KeyFile)
{
SSL_CTX_set_verify(ctx,SSL_VERIFY_NONE,NULL);
SSL_CTX_load_verify_locations(ctx,/home/user/Desktop/CatchChallenger/test/openssl-server/cacert.pem,NULL);
/* set the local certificate from CertFile */
if(SSL_CTX_use_certificate_file(ctx, CertFile, SSL_FILETYPE_PEM)=0)
{
ERR_print_errors_fp(stderr);
abort();
}
/* set the private key from KeyFile (may be the same as CertFile) */
if(SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM)=0)
{
ERR_print_errors_fp(stderr);
abort();
}
/* verify private key */
if(!SSL_CTX_check_private_key(ctx))
{
fprintf(stderr, Private key does not match the public certificate\n);
abort();
}
}
int main(int argc, char *argv[])
{
SSL_library_init(); /* load encryption hash algorithms for SSL */
SSL_load_error_strings(); /* load the error strings for good error reporting */
SSL_CTX *ctx = InitServerCTX();/* initialize SSL */
LoadCertificates(ctx, /home/user/Desktop/CatchChallenger/test/openssl-server/server.crt, /home/user/Desktop/CatchChallenger/test/openssl-server/server.key); /* load certs */
SSL *ssl = SSL_new(ctx);
if(argc != 2)
{
fprintf(stderr, Usage: %s [port]\n, argv[0]);
exit(EXIT_FAILURE);
}
if(!Epoll::epoll.init())
abort();
Server server;
if(!server.tryListen(argv[1]))
abort();
TimerDisplayEventBySeconds timerDisplayEventBySeconds;
if(!timerDisplayEventBySeconds.init())
abort();
char buf[512];
/* Buffer where events are returned */
epoll_event events[MAXEVENTS];
Client* clients[MAXCLIENT];
int clientListSize=0;
/* The event loop */
int number_of_events, i;
while(1)
{
number_of_events = Epoll::epoll.wait(events, MAXEVENTS);
for(i = 0; i number_of_events; i++)
{
switch(static_castBaseClassSwitch *(events[i].data.ptr)-getType())
{
case BaseClassSwitch::Type::Server:
{
if((events[i].events EPOLLERR) ||
(events[i].events EPOLLHUP) ||
(!(events[i].events EPOLLIN) !(events[i].events EPOLLOUT)))
{
/* An error has occured on this fd, or the socket is not
ready for reading (why were we notified then?) */
fprintf(stderr, server epoll error\n);
continue;
}
/* We have a notification on the listening socket, which
means one or more incoming connections. */
while(1)
{
if(clientListSize=MAXCLIENT)
break;
sockaddr in_addr;
socklen_t in_len = sizeof(in_addr);
const int infd = server.accept(in_addr, in_len);
if(infd == -1)
{
if((errno == EAGAIN
Hello, some dev question
Hello,
I have some question:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
What part is global, what part need be do by connexion?
On that's:
https://github.com/alphaonex86/CatchChallenger/blob/master/tools/epoll-with-buffer/main.cpp
I have edited it to try do simple echo server.
The handshake work, but no the echo (don't read any thing).
I try do a sample how do epoll server with SSL support (not found on internet).
And remake this graphic, and comment the code to match with this graphic. And
into C++...
I need too maximum of performance (no client cert), non blocking ops.
Thanks for your help.
--
alpha_one_x86 alpha_one_...@first-world.info
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department
#include sys/epoll.h
#include errno.h
#include iostream
#include list
#include sys/socket.h
#include netdb.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include Client.h
#include Socket.h
#include Server.h
#include Epoll.h
#include Timer.h
#include TimerDisplayEventBySeconds.h
#define MAXEVENTS 512
#define MAXCLIENT 6000
SSL_CTX* InitServerCTX(void)
{
OpenSSL_add_all_algorithms(); /* load register all cryptos, etc. */
SSL_load_error_strings(); /* load all error messages */
const SSL_METHOD *method = TLSv1_2_server_method(); /* create new server-method instance */
SSL_CTX *ctx = SSL_CTX_new(method); /* create new context from method */
if(ctx == NULL)
{
ERR_print_errors_fp(stderr);
abort();
}
return ctx;
}
void LoadCertificates(SSL_CTX* ctx, const char* CertFile, const char* KeyFile)
{
SSL_CTX_set_verify(ctx,SSL_VERIFY_NONE,NULL);
SSL_CTX_load_verify_locations(ctx,/home/user/Desktop/CatchChallenger/test/openssl-server/cacert.pem,NULL);
/* set the local certificate from CertFile */
if(SSL_CTX_use_certificate_file(ctx, CertFile, SSL_FILETYPE_PEM)=0)
{
ERR_print_errors_fp(stderr);
abort();
}
/* set the private key from KeyFile (may be the same as CertFile) */
if(SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM)=0)
{
ERR_print_errors_fp(stderr);
abort();
}
/* verify private key */
if(!SSL_CTX_check_private_key(ctx))
{
fprintf(stderr, Private key does not match the public certificate\n);
abort();
}
}
int main(int argc, char *argv[])
{
SSL_library_init(); /* load encryption hash algorithms for SSL */
SSL_load_error_strings(); /* load the error strings for good error reporting */
SSL_CTX *ctx = InitServerCTX();/* initialize SSL */
LoadCertificates(ctx, /home/user/Desktop/CatchChallenger/test/openssl-server/server.crt, /home/user/Desktop/CatchChallenger/test/openssl-server/server.key); /* load certs */
SSL *ssl = SSL_new(ctx);
if(argc != 2)
{
fprintf(stderr, Usage: %s [port]\n, argv[0]);
exit(EXIT_FAILURE);
}
if(!Epoll::epoll.init())
abort();
Server server;
if(!server.tryListen(argv[1]))
abort();
TimerDisplayEventBySeconds timerDisplayEventBySeconds;
if(!timerDisplayEventBySeconds.init())
abort();
char buf[512];
/* Buffer where events are returned */
epoll_event events[MAXEVENTS];
Client* clients[MAXCLIENT];
int clientListSize=0;
/* The event loop */
int number_of_events, i;
while(1)
{
number_of_events = Epoll::epoll.wait(events, MAXEVENTS);
for(i = 0; i number_of_events; i++)
{
switch(static_castBaseClassSwitch *(events[i].data.ptr)-getType())
{
case BaseClassSwitch::Type::Server:
{
if((events[i].events EPOLLERR) ||
(events[i].events EPOLLHUP) ||
(!(events[i].events EPOLLIN) !(events[i].events EPOLLOUT)))
{
/* An error has occured on this fd, or the socket is not
ready for reading (why were we notified then?) */
fprintf(stderr, server epoll error\n);
continue;
}
/* We have a notification on the listening socket, which
means one or more incoming connections. */
while(1)
{
if(clientListSize=MAXCLIENT)
break;
sockaddr in_addr;
socklen_t in_len = sizeof(in_addr);
const int infd = server.accept(in_addr, in_len);
if(infd == -1)
{
if((errno == EAGAIN) ||
(errno == EWOULDBLOCK))
{
/* We have processed all incoming
connections
openssl-1.0.1e client - fatal alert: Protocol Version (70) at Server Hello
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls smtp -connect DestMTA -msg -debug
, I will get some as:
...
TLS 1.2 Handshake [length 00f4], ClientHello
01 00 00 f0 03 03 53 3a d1 72 61 e9 9f c9 ce dc
97 e0 5d ed 70 b4 2e b5 b2 6c f0 b6 73 28 bf a3
21 6c d0 a7 cc dc 00 00 84 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 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 00 16 00
13 c0 0d c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0
13 c0 09 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 ff 01 00 00
43 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
19 00 18 00 17 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
read from 0x8fd44e0 [0x8fdb340] (7 bytes = 7 (0x7))
- 16 03 02 00 3a 02 :.
0007 - SPACES/NULS
read from 0x8fd44e0 [0x8fdb34a] (56 bytes = 56 (0x38))
- 00 36 03 03 53 3a d1 72-0c 7c 8d 9e 5b ba 26 71 .6..S:.r.|..[.q
0010 - 26 87 fd b1 ec c6 fe 4d-ee 4f d3 03 31 ea f9 2e ..M.O..1...
0020 - 5e 54 fd b8 00 00 9d 00-00 0e ff 01 00 01 00 00 ^T..
0030 - 23 00 00 00 0f 00 01 01- #...
TLS 1.1 Handshake [length 003a], ServerHello
02 00 00 36 03 03 53 3a d1 72 0c 7c 8d 9e 5b ba
26 71 26 87 fd b1 ec c6 fe 4d ee 4f d3 03 31 ea
f9 2e 5e 54 fd b8 00 00 9d 00 00 0e ff 01 00 01
00 00 23 00 00 00 0f 00 01 01
write to 0x8fd44e0 [0x8fe4d50] (7 bytes = 7 (0x7))
- 15 03 03 00 02 02 46 ..F
TLS 1.2 Alert [length 0002], fatal protocol_version
02 46
3070990124:error:1409210A:SSL routines:SSL3_GET_SERVER_HELLO:wrong ssl
version:s3_clnt.c:869:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 297 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher:
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1396363634
Timeout : 300 (sec)
Verify return code: 0 (ok)
which is perhaps same error. On mentioned 's3_clnt.c' line is code:
d=p=(unsigned char *)s-init_msg;
if ((p[0] != (s-version8)) || (p[1] != (s-version0xff)))
{
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_WRONG_SSL_VERSION);
s-version=(s-version0xff00)|p[1];
al=SSL_AD_PROTOCOL_VERSION;
goto f_err;
}
As I'm not programmer, I was not able tracking it more closely, only
I suspect that one version values may be the record layer version
number (0x0302 ~ TLS 1.1) and other may be Server Hello version values
(0x0303 ~ TLS 1.2). But according to e.g. this article:
http://security.stackexchange.com/questions/29314/what-is-the-significance-of-the-version-field-in-a-tls-1-1-clienthello-message
, I cite:
...
The response from the server states the protocol version which will be
used, and should come as records bearing that version. E.g. if the server
says TLS 1.1 in its ServerHello then that ServerHello should come
wrapped into a record also tagged as TLS 1.1; and all subsequent records
from both client and server should use that version.
...
these values _SHOULD_ be same, but I nowhere found that _MUST_ be same.
Thus, I not know, when is problem on remote server side, or in my
sendmail with openssl-1.0.1e.
Can, please, anyone advise what the problem is, and if so, whether
it can be solved on my side?
TIA, Franta Hanzlik
...
No. TimeSourceDestination Protocol Info
4 10.836313 89.24.112.34 85.13.84.100 SMTP S: 220
elfetex.cz Kerio Connect 8.2.2 ESMTP ready
Frame 4: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Routerbo_78:ac:ba (00:0c:42:78:ac:ba), Dst: Intel_bb:7f:e3
(00:02:b3:bb:7f:e3)
Internet Protocol Version 4, Src: 89.24.112.34 (89.24.112.34), Dst:
85.13.84.100 (85.13.84.100)
Transmission Control Protocol, Src Port: 25 (25), Dst Port: 52187 (52187), Seq:
1, Ack: 1, Len: 48
Simple Mail Transfer Protocol
Response: 220 elfetex.cz Kerio Connect 8.2.2 ESMTP ready\r\n
Response code: domain Service ready (220)
Response parameter: elfetex.cz Kerio Connect 8.2.2 ESMTP ready
...
No. TimeSourceDestination Protocol Info
6 10.836414 85.13.84.100
Re: openssl-1.0.1e client - fatal alert: Protocol Version (70) at Server Hello
On Thu, Apr 03, 2014 at 01:18:13PM +0200, Frantisek Hanzlik wrote:
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls smtp -connect DestMTA -msg -debug
I can reproduce this behaviour with the Postfix 2.11 posttls-finger
utility (not surprising really, since it is also linked with
OpenSSL). The behaviour is the same with OpenSSL 1.0.1 and the
1.0.2 version in git.
$ posttls-finger [89.24.112.34]
posttls-finger: Connected to 89.24.112.34[89.24.112.34]:25
posttls-finger: 220 elfetex.cz Kerio Connect 8.2.2 ESMTP ready
posttls-finger: EHLO central-dogma.lan
posttls-finger: 250-elfetex.cz
posttls-finger: 250-AUTH CRAM-MD5 PLAIN LOGIN DIGEST-MD5
posttls-finger: 250-STARTTLS
posttls-finger: 250-ENHANCEDSTATUSCODES
posttls-finger: 250-8BITMIME
posttls-finger: 250-PIPELINING
posttls-finger: 250-ETRN
posttls-finger: 250-DSN
posttls-finger: 250 HELP
posttls-finger: STARTTLS
posttls-finger: 220 2.0.0 Ready to start TLS
posttls-finger: SSL_connect error to 89.24.112.34[89.24.112.34]:25: -1
posttls-finger: warning: TLS library problem: error:1409210A:SSL
routines:SSL3_GET_SERVER_HELLO:wrong ssl version:s3_clnt.c:868:
Indeed that server's response is TLS 1.1 {3, 2} at the record layer, and
TLS 1.2 {3, 3} in the server HELLO. I don't know whether rejecting
such server responses is the right behaviour, or whether the OpenSSL
client should tolerate this.
For what it is worth, Postfix will retry in cleartext after an
opportunistic TLS handshake fails. Does Sendmail not fall back to
cleartext?
--
Viktor
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: openssl-1.0.1e client - fatal alert: Protocol Version (70) at Server Hello
Viktor Dukhovni wrote:
On Thu, Apr 03, 2014 at 01:18:13PM +0200, Frantisek Hanzlik wrote:
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls smtp -connect DestMTA -msg -debug
I can reproduce this behaviour with the Postfix 2.11 posttls-finger
utility (not surprising really, since it is also linked with
OpenSSL). The behaviour is the same with OpenSSL 1.0.1 and the
1.0.2 version in git.
$ posttls-finger [89.24.112.34]
posttls-finger: Connected to 89.24.112.34[89.24.112.34]:25
posttls-finger: 220 elfetex.cz Kerio Connect 8.2.2 ESMTP ready
posttls-finger: EHLO central-dogma.lan
posttls-finger: 250-elfetex.cz
posttls-finger: 250-AUTH CRAM-MD5 PLAIN LOGIN DIGEST-MD5
posttls-finger: 250-STARTTLS
posttls-finger: 250-ENHANCEDSTATUSCODES
posttls-finger: 250-8BITMIME
posttls-finger: 250-PIPELINING
posttls-finger: 250-ETRN
posttls-finger: 250-DSN
posttls-finger: 250 HELP
posttls-finger: STARTTLS
posttls-finger: 220 2.0.0 Ready to start TLS
posttls-finger: SSL_connect error to 89.24.112.34[89.24.112.34]:25: -1
posttls-finger: warning: TLS library problem: error:1409210A:SSL
routines:SSL3_GET_SERVER_HELLO:wrong ssl version:s3_clnt.c:868:
Indeed that server's response is TLS 1.1 {3, 2} at the record layer, and
TLS 1.2 {3, 3} in the server HELLO. I don't know whether rejecting
such server responses is the right behaviour, or whether the OpenSSL
client should tolerate this.
For what it is worth, Postfix will retry in cleartext after an
opportunistic TLS handshake fails. Does Sendmail not fall back to
cleartext?
Hello Viktor, thaks for looking at this problem.
As I know, Sendmail from Sendmail.org do not know fall back to cleartext
when this type of TLS error occurs. Sendmail tells them as 'SOFTWARE'
errors and mails where these errors occurs will be queued for later
delivery - and after several days of futile delivery attempts will
be deleted from queue. Only way how avoid this situation for one
particular mailserver is using Try_TLS:SERVERIP/FQDN NO in access
map, which disable STARTTLS for this server even if it announce STARTTLS
in its EHLO reply.
If I guess correctly, there isn't clear rule how treat cases, where
server tell lower TLS version in its record layer than TLS version
which choose for connection and tells it in server HELLO ?
PS: Please, excuse me for posting my mail twice - I have not got it
back from list (it was sent, but rejected with my antispam rule
mails from me to me sent from internet must be sent over cryped and
authenticated connection), and I could not find it either on the
marc.info openssl archive. I found it to tonight on mail-archive.com.
Thanks, Franta Hanzlik
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
openssl-1.0.1e client - fatal alert: Protocol Version (70) at Server Hello
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls smtp -connect DestMTA -msg -debug
, I will get some as:
...
TLS 1.2 Handshake [length 00f4], ClientHello
01 00 00 f0 03 03 53 3a d1 72 61 e9 9f c9 ce dc
97 e0 5d ed 70 b4 2e b5 b2 6c f0 b6 73 28 bf a3
21 6c d0 a7 cc dc 00 00 84 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 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 00 16 00
13 c0 0d c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0
13 c0 09 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 ff 01 00 00
43 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
19 00 18 00 17 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
read from 0x8fd44e0 [0x8fdb340] (7 bytes = 7 (0x7))
- 16 03 02 00 3a 02 :.
0007 - SPACES/NULS
read from 0x8fd44e0 [0x8fdb34a] (56 bytes = 56 (0x38))
- 00 36 03 03 53 3a d1 72-0c 7c 8d 9e 5b ba 26 71 .6..S:.r.|..[.q
0010 - 26 87 fd b1 ec c6 fe 4d-ee 4f d3 03 31 ea f9 2e ..M.O..1...
0020 - 5e 54 fd b8 00 00 9d 00-00 0e ff 01 00 01 00 00 ^T..
0030 - 23 00 00 00 0f 00 01 01- #...
TLS 1.1 Handshake [length 003a], ServerHello
02 00 00 36 03 03 53 3a d1 72 0c 7c 8d 9e 5b ba
26 71 26 87 fd b1 ec c6 fe 4d ee 4f d3 03 31 ea
f9 2e 5e 54 fd b8 00 00 9d 00 00 0e ff 01 00 01
00 00 23 00 00 00 0f 00 01 01
write to 0x8fd44e0 [0x8fe4d50] (7 bytes = 7 (0x7))
- 15 03 03 00 02 02 46 ..F
TLS 1.2 Alert [length 0002], fatal protocol_version
02 46
3070990124:error:1409210A:SSL routines:SSL3_GET_SERVER_HELLO:wrong ssl
version:s3_clnt.c:869:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 297 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher:
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1396363634
Timeout : 300 (sec)
Verify return code: 0 (ok)
which is perhaps same error. On mentioned 's3_clnt.c' line is code:
d=p=(unsigned char *)s-init_msg;
if ((p[0] != (s-version8)) || (p[1] != (s-version0xff)))
{
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_WRONG_SSL_VERSION);
s-version=(s-version0xff00)|p[1];
al=SSL_AD_PROTOCOL_VERSION;
goto f_err;
}
As I'm not programmer, I was not able tracking it more closely, only
I suspect that one version values may be the record layer version
number (0x0302 ~ TLS 1.1) and other may be Server Hello version values
(0x0303 ~ TLS 1.2). But according to e.g. this article:
http://security.stackexchange.com/questions/29314/what-is-the-significance-of-the-version-field-in-a-tls-1-1-clienthello-message
, I cite:
...
The response from the server states the protocol version which will be
used, and should come as records bearing that version. E.g. if the server
says TLS 1.1 in its ServerHello then that ServerHello should come
wrapped into a record also tagged as TLS 1.1; and all subsequent records
from both client and server should use that version.
...
these values _SHOULD_ be same, but I nowhere found that _MUST_ be same.
Thus, I not know, when is problem on remote server side, or in my
sendmail with openssl-1.0.1e.
Can, please, anyone advise what the problem is, and if so, whether
it can be solved on my side?
TIA, Franta Hanzlik
...
No. TimeSourceDestination Protocol Info
4 10.836313 89.24.112.34 85.13.84.100 SMTP S: 220
elfetex.cz Kerio Connect 8.2.2 ESMTP ready
Frame 4: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Routerbo_78:ac:ba (00:0c:42:78:ac:ba), Dst: Intel_bb:7f:e3
(00:02:b3:bb:7f:e3)
Internet Protocol Version 4, Src: 89.24.112.34 (89.24.112.34), Dst:
85.13.84.100 (85.13.84.100)
Transmission Control Protocol, Src Port: 25 (25), Dst Port: 52187 (52187), Seq:
1, Ack: 1, Len: 48
Simple Mail Transfer Protocol
Response: 220 elfetex.cz Kerio Connect 8.2.2 ESMTP ready\r\n
Response code: domain Service ready (220)
Response parameter: elfetex.cz Kerio Connect 8.2.2 ESMTP ready
...
No. TimeSourceDestination Protocol Info
6 10.836414 85.13.84.100
Re: CentOS 5; openssl1.0.1e; SSL_accept:error in SSLv2/v3 read client hello A
solved. libcurl (which I used for soap server) linked openssl version from the system, not from project -- View this message in context: http://openssl.6102.n7.nabble.com/CentOS-5-openssl1-0-1e-SSL-accept-error-in-SSLv2-v3-read-client-hello-A-tp46479p46545.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CentOS 5; openssl1.0.1e; SSL_accept:error in SSLv2/v3 read client hello A
Hi, I use standard scheme to send/receive SOAP requests over TLS. On Windows it works good, server receive request from client, it handles correctly. On Linux I have the following error: SSL_accept:error in SSLv2/v3 read client hello A In the 'verify callback' which I've set in SSL_CTX_set_verify I receive 'store' object which doesn't contain SSL object: X509_STORE_CTX_get_ex_data(store, SSL_get_ex_data_X509_STORE_CTX_idx()) return NULL. I use the OpenSSL 1.0.1e with fips 2.0.4 both on windows and linux. Here is code fragments how I use OpenSSL soap-ctx = SSL_CTX_new(SSLv23_method()) ... SSL_CTX_set_options(soap-ctx, (SSL_OP_ALL | SSL_OP_NO_SSLv2)); SSL_CTX_set_cipher_list(soap-ctx, m_cipherSuite) SSL_CTX_set_verify(soap-ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, tls_soap_verify_callback); ... soap.ssl = SSL_new(soap-ctx); ... SSL_accept(soap-ssl) This issue on Linux was disappeared when I decided to debug openssl and built it with debug-rse flag (I found advice to use it in the internet). Could anybody please help with this issue? What should be corrected in the code to use standard release openssl version instead of debug. I will send additional info if it's needed. Thanks in advance! -- View this message in context: http://openssl.6102.n7.nabble.com/CentOS-5-openssl1-0-1e-SSL-accept-error-in-SSLv2-v3-read-client-hello-A-tp46479.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Issue: Client Hello advertises 2 cipher suites.
Thanks Dave. Yep the other person is my senior and since I didn't have an user forum registration at that moment, so asked him to drop the question on my behalf. Sorry for the inconvenience. Regards Tanmoy Sinha http://tanmoyspeaks.blogspot.com On Mon, Jul 1, 2013 at 4:04 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Tanmoy Sinha Sent: Friday, 28 June, 2013 04:29 I am using a client application program which uses OpenSSL version 1.0.0h. I configured TLSv1.2 and I have set the cipher suite only as TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 [...but] Client Hello Message [also has] TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 Same question (with same mistake) asked by allegedly different person Fri and answered. Please read that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Issue: Client Hello advertises 2 cipher suites.
From: owner-openssl-us...@openssl.org On Behalf Of Tanmoy Sinha Sent: Friday, 28 June, 2013 04:29 I am using a client application program which uses OpenSSL version 1.0.0h. I configured TLSv1.2 and I have set the cipher suite only as TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 [...but] Client Hello Message [also has] TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 Same question (with same mistake) asked by allegedly different person Fri and answered. Please read that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Issue: Client Hello advertises 2 cipher suites.
Hi, I am using a client application program which uses OpenSSL version 1.0.0h. I configured TLSv1.2 and I have set the cipher suite only as TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. ECDH-ECDSA-AES128-SHA256) using the API SSL_CTX_set_cipher_list(). But what I find in packet capture, is that in Client Hello Message there are 2 advertised ciphers suites. The first one is TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 and second cipher suite is TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. the one we requested), although I've set only one cipher suite. Moreover, my server application selects the the first advertised cipher suite and carries on the handshake. Can someone explain this behavior? My requirement is to have the session to use TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 this cipher suite only. What needs to be done for this. Regards Tanmoy Sinha
Client Hello advertises 2 cipher suites
Hi, I am using a client application program which uses OpenSSL version 1.0.0h. I configured TLSv1.2 and I have set the cipher suite only as TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. ECDH-ECDSA-AES128-SHA256) using the API SSL_CTX_set_cipher_list(). But what I find in packet capture, is that in Client Hello Message there are 2 advertised ciphers suites. The first one is TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 and second cipher suite is TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. the one we requested), although I've set only one cipher suite. Moreover, my server application selects the the first advertised cipher suite and carries on the handshake. Can someone explain this behaviour? My requirement is to have the session to use TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 this cipher suite only. What needs to be done for this. Regards Suryya
RE: Client Hello advertises 2 cipher suites
From: owner-openssl-us...@openssl.org On Behalf Of Suryya Kumar Jana Sent: Friday, 28 June, 2013 05:34 I am using a client application program which uses OpenSSL version 1.0.0h. I configured TLSv1.2 and I have set the cipher suite only as TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. ECDH-ECDSA-AES128-SHA256) using the API SSL_CTX_set_cipher_list(). I think you're mistaken about 1.0.0h, unless it's a patched version. TLSv1.1 and 1.2 protocols, and the 1.2-specific suites (SHA-2 and GCM), were added only in 1.0.1. But what I find in packet capture, is that in Client Hello Message there are 2 advertised ciphers suites. The first one is TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 and second cipher suite is TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 snip 1.0.1c and I believe earlier but not tested had several bugs in selecting kECDH and TLSv1.2 ciphers fixed in 1.0.1e. (Also kDH, but those aren't implemented anyway.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client Hello advertises 2 cipher suites
On Fri, Jun 28, 2013, Dave Thompson wrote: 1.0.1c and I believe earlier but not tested had several bugs in selecting kECDH and TLSv1.2 ciphers fixed in 1.0.1e. (Also kDH, but those aren't implemented anyway.) Actually fixed DH is implemented now. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CBC issue with 1.0.1e?: hello timeout again
Thanks for the reply. Using a lower version of TLS solved it for us. //Toland (^_^x) On May 30, 2013, at 10:29 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Toland Hon Sent: Thursday, 30 May, 2013 22:22 I'm on Mac running OS X 10.8.3 and have 2 versions of openssl installed: *Default: OpenSSL 0.9.8r 8 Feb 2011 *Homebrew: OpenSSL 1.0.1e 11 Feb 2013 My most recent version of ruby (1.9.3-p429) is linked with Homebrew's openssl and [] I began having [timeout] to a particular website. I noticed there was a recent security bulletin and a fix in regards to CBC ciphers: http://www.openssl.org/news/secadv_20130205.txt I was curious if this security fix introduced a bug that has problems connecting to certain websites using CBC cipher snip or is there something incorrectly configured on this server? The Lucky13 issue wouldn't affect handshake at all. It would affect performance during data phase if there is (underlying) data alteration accidentally or due to attack. This is most likely another case of the frequently reported (and discussed) issue that 1.0.1 implements TLS1.2, which has more ciphersuites enabled by default and additional extensions, which together make the ClientHello bigger, and some server implementations apparently can't cope. It appears in at least many cases the cutoff is 256 bytes, suggesting these servers don't handle 2-byte length right. It's unlikely that this would be explicitly configured on a server, rather it would be an implementation flaw that previously did not cause a problem. It might occur in an older version of server software fixed in a newer version. For many details see http://rt.openssl.org/Ticket/Display.html?id=2771user=guestpass=guest Short answer is that restricting to TLS1(.0), and/or a smaller list of ciphersuites (but still enough to intersect with the server), likely works. Both do for me using 1.0.1e to your example host. You can use -msg in s_client to see exactly how much (and what) is sent for different options. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Restricting ciphers list to RSA only in Client Hello
hi Kshirsagar, I am into the same scenario, can you tell me at which end you are setting the cipher list? Do we have to make changes on client application end ? The parameters you mentioned, SSL_DEFAULT_CIPHER_LIST, can be seen on server end , into openssl ssl.h file. Could you describe what changes can be done on server end to get the required cipher ? I have Linphone at app end, openssl version 1.0.0 And SIP Server | openssl 1.0.1c. -- View this message in context: http://openssl.6102.n7.nabble.com/Restricting-ciphers-list-to-RSA-only-in-Client-Hello-tp28933p45378.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: CBC issue with 1.0.1e?: hello timeout again
From: owner-openssl-us...@openssl.org On Behalf Of Toland Hon Sent: Thursday, 30 May, 2013 22:22 I'm on Mac running OS X 10.8.3 and have 2 versions of openssl installed: * Default: OpenSSL 0.9.8r 8 Feb 2011 * Homebrew: OpenSSL 1.0.1e 11 Feb 2013 My most recent version of ruby (1.9.3-p429) is linked with Homebrew's openssl and [] I began having [timeout] to a particular website. I noticed there was a recent security bulletin and a fix in regards to CBC ciphers: http://www.openssl.org/news/secadv_20130205.txt I was curious if this security fix introduced a bug that has problems connecting to certain websites using CBC cipher snip or is there something incorrectly configured on this server? The Lucky13 issue wouldn't affect handshake at all. It would affect performance during data phase if there is (underlying) data alteration accidentally or due to attack. This is most likely another case of the frequently reported (and discussed) issue that 1.0.1 implements TLS1.2, which has more ciphersuites enabled by default and additional extensions, which together make the ClientHello bigger, and some server implementations apparently can't cope. It appears in at least many cases the cutoff is 256 bytes, suggesting these servers don't handle 2-byte length right. It's unlikely that this would be explicitly configured on a server, rather it would be an implementation flaw that previously did not cause a problem. It might occur in an older version of server software fixed in a newer version. For many details see http://rt.openssl.org/Ticket/Display.html?id=2771user=guestpass=guest Short answer is that restricting to TLS1(.0), and/or a smaller list of ciphersuites (but still enough to intersect with the server), likely works. Both do for me using 1.0.1e to your example host. You can use -msg in s_client to see exactly how much (and what) is sent for different options. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
reject client hello
Hi All, I would like to reject if the client hello doesn't contain secure renegotiation info(RFC 5746). I could close the ssl connection after it established. As per the RFC 5746 section 4.3 server shall terminate the connection immediately upon failure to negotiate the use of secure renegotiation Is it possible to reject as soon as i receive client hello message.? If so how can i do it. Thanks JJ
Hello
wow this is pretty awesome you should give it a look http://www.finance15dynews.net/biz/?read=9799495 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On 15/04/12 23:33, Dr. Stephen Henson wrote: On Sun, Apr 15, 2012, Jeffrey Walton wrote: On Sun, Apr 15, 2012 at 12:01 PM,toredhiddenu...@tormail.net wrote: Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? Point counting is tricky business. I believe it is the reason most folks (OpenSSL, Crypto++, NSS, etc) stick with well known curves. I don't know how to plug in a custom curve with OpenSSL (I have never had a need to do it), but I do know how with Crypto++. If I wanted to do so, I would use Marcel Martin's Elliptic Curve Builder (ECB) to generate domain parameters to meet security levels. It should be possible to use a non-named curve with the appropriate encoding of the ECParameters structure. I've never had to do this either. The library only supports Fp and F2^m custom curves. The easiest way to construct a custom curve is by using one of: EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); Where for an Fp curve p, a and b are used as follows: y^2 mod p = x^3 +ax + b mod p And for an F2^m curve p (p=2^m), a and b are: y^2 + xy mod p = x^3 + ax^2 + b (where b != 0) mod p Matt 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org So, do you say it can't be done with executable? Will this be a feature in future releases? Are you sure there's no way to do that than digging the C source? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On 17/04/12 06:57, toredhiddenu...@tormail.net wrote: The library only supports Fp and F2^m custom curves. The easiest way to construct a custom curve is by using one of: EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); Where for an Fp curve p, a and b are used as follows: y^2 mod p = x^3 +ax + b mod p And for an F2^m curve p (p=2^m), a and b are: y^2 + xy mod p = x^3 + ax^2 + b (where b != 0) mod p Matt So, do you say it can't be done with executable? Will this be a feature in future releases? Are you sure there's no way to do that than digging the C source? Well ultimately openssl is a library. The functions I mention above are part of the public API so you don't need to modify the openssl source to use them. It does require programming though. From your question I assume you are referring to the openssl command line tool. I am not particularly familiar with the command line tool as most of my work has been with the library directly. However I would be surprised if you can define custom curves using it...that's fairly advanced stuff that most users are never going to need to use (nor would it be advisable for them to do so). In almost all cases using a standard curve will be sufficient - and its by far the safest option. In terms of future support for new curves, I imagine that is going to be driven by the standards. As curves get defined and standardised they will work their way into openssl. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On 15/04/12 23:33, Dr. Stephen Henson wrote: On Sun, Apr 15, 2012, Jeffrey Walton wrote: On Sun, Apr 15, 2012 at 12:01 PM,toredhiddenu...@tormail.net wrote: Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? Point counting is tricky business. I believe it is the reason most folks (OpenSSL, Crypto++, NSS, etc) stick with well known curves. I don't know how to plug in a custom curve with OpenSSL (I have never had a need to do it), but I do know how with Crypto++. If I wanted to do so, I would use Marcel Martin's Elliptic Curve Builder (ECB) to generate domain parameters to meet security levels. It should be possible to use a non-named curve with the appropriate encoding of the ECParameters structure. I've never had to do this either. The library only supports Fp and F2^m custom curves. The easiest way to construct a custom curve is by using one of: EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); Where for an Fp curve p, a and b are used as follows: y^2 mod p = x^3 +ax + b mod p And for an F2^m curve p (p=2^m), a and b are: y^2 + xy mod p = x^3 + ax^2 + b (where b != 0) mod p Matt 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Hello guyz and cryptobrains! :P
Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On Sun, Apr 15, 2012 at 12:01 PM, toredhiddenu...@tormail.net wrote: Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? Point counting is tricky business. I believe it is the reason most folks (OpenSSL, Crypto++, NSS, etc) stick with well known curves. I don't know how to plug in a custom curve with OpenSSL (I have never had a need to do it), but I do know how with Crypto++. If I wanted to do so, I would use Marcel Martin's Elliptic Curve Builder (ECB) to generate domain parameters to meet security levels. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On 15/04/12 17:01, toredhiddenu...@tormail.net wrote: Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Well, there are a few points to consider here. First of all there is nothing about the openssl EC library that restricts the key length. It is perfectly possible to define curves which support key lengths of any size that you desire. However, the library provides numerous standard curves (which support specific defined key lengths) for you to use which in most circumstances are going to be perfectly acceptable. I wouldn't recommend defining your own curve unless you really know what you are doing. If however you can find a curve that supports the key length you want, then you can use the library to create it. Secondly you cannot directly compare RSA key lengths and EC key lengths. RSA keys are *much* longer than the equivalent EC key size for the same security...and the effect becomes more pronounced the more security that you desire. So: An RSA key size of 1024 bits is equivalent to 160 bits EC (or 80 bit symmetric such as AES) RSA key size of 3072 bits is equivalent to 256 bits EC (or 128 bit symmetric) RSA key size of *15360* bits is equivalent to 512 bits EC (or 256 bit symmetric) Finally of course that whilst it is possible to define very long key sizes for RSA the practicalities of doing so mean that using EC is by far the better choice. Consider the performance difference you are likely to get working with 15360 bit numbers compared with 512 for EC! Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On Sun, Apr 15, 2012, Jeffrey Walton wrote: On Sun, Apr 15, 2012 at 12:01 PM, toredhiddenu...@tormail.net wrote: Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? Point counting is tricky business. I believe it is the reason most folks (OpenSSL, Crypto++, NSS, etc) stick with well known curves. I don't know how to plug in a custom curve with OpenSSL (I have never had a need to do it), but I do know how with Crypto++. If I wanted to do so, I would use Marcel Martin's Elliptic Curve Builder (ECB) to generate domain parameters to meet security levels. It should be possible to use a non-named curve with the appropriate encoding of the ECParameters structure. I've never had to do this either. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On Sun, Apr 15, 2012, Matt Caswell (fr...@baggins.org) wrote: First of all there is nothing about the openssl EC library that restricts the key length. Well there is a limit on key sizes for public key algorithms to avoid their use as a DoS attack. This limit is currently 661 bits for EC keys and 16384 bits for RSA keys. The limits can be increased at compile time. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On Sun, Apr 15, 2012 at 12:01 PM, toredhiddenu...@tormail.net wrote: Hello guyz and cryptobrains! :P One of the main disadvantages of EC on openssl seems to be the inability to create arbitrary-sized keys and advantage for RSA: you can create 32768 bit RSA key but... not greater than 521 bits on ECC. Will this continue to be a disadvantage or can 32768 RSA key be used instead? Point counting is tricky business. I believe it is the reason most folks (OpenSSL, Crypto++, NSS, etc) stick with well known curves. I don't know how to plug in a custom curve with OpenSSL (I have never had a need to do it), but I do know how with Crypto++. If I wanted to do so, I would use Marcel Martin's Elliptic Curve Builder (ECB) to generate domain parameters to meet security levels. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Ewww... It's proprietary! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
hello!
I've just started using openssl, and have been having some problems with
valgrind. Here's my distilled test program:
#include openssl-1.0.0e/include/openssl/hmac.h
#include openssl-1.0.0e/include/openssl/evp.h
#include string.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
HMAC_CTX_init(context);
HMAC_Init_ex(context, key, sizeof(key), EVP_sha1(), NULL);
return 0;
}
I used ./config for setup on RedHat, and got linux-elf as my configuration.
To compile the test program:
g++ -o ot -ggdb -I/home/bertoni/src/ ot.c -L. -ltestcrypto -ldl
after installing libcrypto.a as libtestcrypto.a
When I run it under valgrind, I get errors:
==30797== Invalid write of size 1
==30797==at 0x400655C: memset (mc_replace_strmem.c:479)
==30797==by 0x804959D: HMAC_Init_ex (hmac.c:100)
==30797== Address 0x40160E0 is 0 bytes after a block of size 184 alloc'd
==30797==at 0x40053C0: malloc (vg_replace_malloc.c:149)
==30797==by 0x80491F0: main (ot.c:12)
and so on.
The hmactest program run is clean, so I'm not sure what I'm doing
incorrectly.. Any pointers would be appreciated.
Jon Bertoni
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: hello!
#include openssl-1.0.0e/include/openssl/hmac.h
#include openssl-1.0.0e/include/openssl/evp.h
#include string.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
Do you need to malloc the context (a pointer) ?
I don't think so.
Remove the line?
HMAC_CTX_init(context);
HMAC_Init_ex(context, key, sizeof(key), EVP_sha1(), NULL);
return 0;
}
I used ./config for setup on RedHat, and got linux-elf as my configuration.
To compile the test program:
g++ -o ot -ggdb -I/home/bertoni/src/ ot.c -L. -ltestcrypto -ldl
after installing libcrypto.a as libtestcrypto.a
When I run it under valgrind, I get errors:
==30797== Invalid write of size 1
==30797==at 0x400655C: memset (mc_replace_strmem.c:479)
==30797==by 0x804959D: HMAC_Init_ex (hmac.c:100)
==30797== Address 0x40160E0 is 0 bytes after a block of size 184 alloc'd
==30797==at 0x40053C0: malloc (vg_replace_malloc.c:149)
==30797==by 0x80491F0: main (ot.c:12)
and so on.
The hmactest program run is clean, so I'm not sure what I'm doing
incorrectly.. Any pointers would be appreciated.
Jon Bertoni
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: hello!
Jonas Schnelli
jonas.schne...@include7.ch writes:
#include openssl-1.0.0e/include/openssl/hmac.h
#include openssl-1.0.0e/include/openssl/evp.h
#include string.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
Do you need to malloc the context (a pointer) ?
I don't think so.
Remove the line?
That won't work, but you can do
HMAC_CTX context;
and use context instead of context.
HMAC_CTX_init(context);
HMAC_Init_ex(context, key, sizeof(key), EVP_sha1(), NULL);
return 0;
}
The program runs fine under valgrind on my Fedora 14. Have you built
your openssl in a weird way (and why is it named libtestcrypto)?
(I had to add HMAC_CTX_cleanup(context) and free(context) to avoid
memory leak warnings from valgrind, though.)
--
Henrik Grindal Bakken h...@ifi.uio.no
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: hello!
On 11/15/2011 11:39 AM, Henrik Grindal Bakken wrote:
Jonas Schnelli
jonas.schne...@include7.ch writes:
#includeopenssl-1.0.0e/include/openssl/hmac.h
#includeopenssl-1.0.0e/include/openssl/evp.h
#includestring.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
Do you need to malloc the context (a pointer) ?
I don't think so.
Remove the line?
That won't work, but you can do
HMAC_CTX context;
and usecontext instead of context.
Why would that be any different?
When OpenSSL gets a HMAC_CTX*, it shouldn't care if it points to
memory on the stack or the heap, as long as that memory is
sizeof(HMAC_CTX) big and maybe appropriately initialized.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: hello!
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
Sent: Tuesday, November 15, 2011 2:28 PM
On 11/15/2011 11:39 AM, Henrik Grindal Bakken wrote:
Jonas Schnelli
jonas.schne...@include7.ch writes:
#includeopenssl-1.0.0e/include/openssl/hmac.h
#includeopenssl-1.0.0e/include/openssl/evp.h
#includestring.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
Do you need to malloc the context (a pointer) ?
I don't think so.
Remove the line?
That won't work, but you can do
HMAC_CTX context;
and usecontext instead of context.
Why would that be any different?
When OpenSSL gets a HMAC_CTX*, it shouldn't care if it points to
memory on the stack or the heap, as long as that memory is
sizeof(HMAC_CTX) big and maybe appropriately initialized.
Err ... yes, that's the point. The original code used malloc to allocate memory
for an HMAC_CTX, and did it right (apart from not checking that malloc
succeeded). Henrik's version allocated memory for an HMAC_CTX structure
automatically, and was equally right. Jonas's version didn't allocate memory
for an HMAC_CTX at all, and passed an uninitialized pointer to subsequent
function calls instead of a pointer to an HMAC_CTX.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
hello my dear
it is really best place for us i had try , it is truth and service is very good fast ship and best quality hope you can try too here is : www.bestsker.com enjoy yourself
Re: Client Hello too large ?
On Mon June 20 2011, Alban Diquet wrote: Hi all, I've encountered a strange issue. It might not be related to OpenSSL itself, but maybe it is. When sending a Client Hello message that's larger than 270 bytes (not sure what the exact limit is, 255 maybe?), lots of servers on the internet don't send back any Server Hello, but keep the connection open, so my client ends up returning a timeout. It's really weird, has anyone seen that behavior ? You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d with a TLS1 hello, all the cipher suites explicitly enabled 'ALL:NULL:@STRENGTH', and a non empty session ID field. Is that session ID still valid on the server when this happens? Is it a session ID that the server issued to your client? Mike Then feel free to test it on Facebook. Does anyone know what's going on there ? Thanks, Alban Diquet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client Hello too large ?
On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote: I've encountered a strange issue. It might not be related to OpenSSL itself, but maybe it is. When sending a Client Hello message that's larger than 270 bytes (not sure what the exact limit is, 255 maybe?), lots of servers on the internet don't send back any Server Hello, but keep the connection open, so my client ends up returning a timeout. It's really weird, has anyone seen that behavior ? You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d with a TLS1 hello, all the cipher suites explicitly enabled 'ALL:NULL:@STRENGTH', and a non empty session ID field. Is that session ID still valid on the server when this happens? Is it a session ID that the server issued to your client? I can reproduce this problem, perhaps it is an issue with the load balancers that terminate TLS at many large-scale HTTPS-enabled sites. For facebook, try: $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443 The above hangs on the reconnect client hello, while: $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443 yields: Reused, TLSv1/SSLv3, Cipher is RC4-MD5 Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 Session-ID: 197E266EAC6CDD1CA9BAFD0AFB6EDB9CB63407EC1046131A59F33766BF3BB5E9 Session-ID-ctx: Master-Key: ... Key-Arg : None PSK identity: None PSK identity hint: None Start Time: 1308667111 Timeout : 7200 (sec) Verify return code: 20 (unable to get local issuer certificate) So session re-use works, but not when the hello is: TLS 1.0 Handshake [length 0118], ClientHello 01 00 01 14 03 01 4e 00 ad 60 11 e7 93 d1 b3 46 8f be 77 1d 68 c5 dd c0 d2 94 60 f5 32 b3 e5 ee 68 a6 e4 c5 0a da 20 19 7e 26 6e ac 6c a4 43 a9 ba fd 0a fb 6e dd 9d da dd af f4 4c d9 d5 56 59 f3 37 66 bf 3b b4 70 00 86 c0 14 c0 0a 00 39 00 38 00 88 00 87 c0 19 00 3a 00 89 c0 0f c0 05 00 35 00 84 c0 12 c0 08 00 16 00 13 c0 17 00 1b c0 0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00 99 00 45 00 44 c0 18 00 34 00 9b 00 46 c0 0e c0 04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 16 00 18 c0 0c c0 02 00 05 00 04 00 15 00 12 00 1a 00 09 00 14 00 11 00 19 00 08 00 06 00 17 00 03 c0 10 c0 06 c0 15 c0 0b c0 01 00 02 00 01 00 ff 02 01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f 00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 18 00 19 00 23 00 00 as with 'ALL:NULL:@STRENGTH'. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client Hello too large ?
Yes, strange isn't it ? I guess it doesn't matter for 99% of the SSL clients, but for what I'm doing (a SSL scanner) it's kind of annoying. Well it's probably not going to change anytime soon, but now I want to know what's going on. Alban 2011/6/21 Victor Duchovni victor.ducho...@morganstanley.com On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote: I've encountered a strange issue. It might not be related to OpenSSL itself, but maybe it is. When sending a Client Hello message that's larger than 270 bytes (not sure what the exact limit is, 255 maybe?), lots of servers on the internet don't send back any Server Hello, but keep the connection open, so my client ends up returning a timeout. It's really weird, has anyone seen that behavior ? You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d with a TLS1 hello, all the cipher suites explicitly enabled 'ALL:NULL:@STRENGTH', and a non empty session ID field. Is that session ID still valid on the server when this happens? Is it a session ID that the server issued to your client? I can reproduce this problem, perhaps it is an issue with the load balancers that terminate TLS at many large-scale HTTPS-enabled sites. For facebook, try: $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443 The above hangs on the reconnect client hello, while: $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443 yields: Reused, TLSv1/SSLv3, Cipher is RC4-MD5 Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 Session-ID: 197E266EAC6CDD1CA9BAFD0AFB6EDB9CB63407EC1046131A59F33766BF3BB5E9 Session-ID-ctx: Master-Key: ... Key-Arg : None PSK identity: None PSK identity hint: None Start Time: 1308667111 Timeout : 7200 (sec) Verify return code: 20 (unable to get local issuer certificate) So session re-use works, but not when the hello is: TLS 1.0 Handshake [length 0118], ClientHello 01 00 01 14 03 01 4e 00 ad 60 11 e7 93 d1 b3 46 8f be 77 1d 68 c5 dd c0 d2 94 60 f5 32 b3 e5 ee 68 a6 e4 c5 0a da 20 19 7e 26 6e ac 6c a4 43 a9 ba fd 0a fb 6e dd 9d da dd af f4 4c d9 d5 56 59 f3 37 66 bf 3b b4 70 00 86 c0 14 c0 0a 00 39 00 38 00 88 00 87 c0 19 00 3a 00 89 c0 0f c0 05 00 35 00 84 c0 12 c0 08 00 16 00 13 c0 17 00 1b c0 0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00 99 00 45 00 44 c0 18 00 34 00 9b 00 46 c0 0e c0 04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 16 00 18 c0 0c c0 02 00 05 00 04 00 15 00 12 00 1a 00 09 00 14 00 11 00 19 00 08 00 06 00 17 00 03 c0 10 c0 06 c0 15 c0 0b c0 01 00 02 00 01 00 ff 02 01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f 00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 18 00 19 00 23 00 00 as with 'ALL:NULL:@STRENGTH'. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client Hello too large ?
Am 21.06.2011 20:38, schrieb Alban Diquet: Yes, strange isn't it ? I guess it doesn't matter for 99% of the SSL clients, but for what I'm doing (a SSL scanner) it's kind of annoying. Well it's probably not going to change anytime soon, but now I want to know what's going on. When sending a Client Hello message that's larger than 270 bytes (not sure what the exact limit is, 255 maybe?), lots of servers on the internet don't send back any Server Hello, but keep the connection open, so my client ends up returning a timeout. It's really weird, has anyone seen that behavior ? You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d with a TLS1 hello, all the cipher suites explicitly enabled 'ALL:NULL:@STRENGTH', and a non empty session ID field. Is that session ID still valid on the server when this happens? Is it a session ID that the server issued to your client? I can reproduce this problem, perhaps it is an issue with the load balancers that terminate TLS at many large-scale HTTPS-enabled sites. For facebook, try: $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443 http://69.171.224.40:443 The above hangs on the reconnect client hello, while: $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443 http://69.171.224.40:443 yields: It may actually be worth connecting the respective system administrator(s). Finally you are not just wasting your system's rescources. You are also wasting theirs. We don't know what kind of resources you are wasting. It will most likely only be a file descriptor on the other side (hopefully for a service like facebook they have plenty of these :-). If you are triggering more resource hungry effects (memory, CPU cycles) while you see no response, you might have found a DoS on their side. Best regards, Lutz
Client Hello too large ?
Hi all, I've encountered a strange issue. It might not be related to OpenSSL itself, but maybe it is. When sending a Client Hello message that's larger than 270 bytes (not sure what the exact limit is, 255 maybe?), lots of servers on the internet don't send back any Server Hello, but keep the connection open, so my client ends up returning a timeout. It's really weird, has anyone seen that behavior ? You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d with a TLS1 hello, all the cipher suites explicitly enabled 'ALL:NULL:@STRENGTH', and a non empty session ID field. Then feel free to test it on Facebook. Does anyone know what's going on there ? Thanks, Alban Diquet
Re: Restricting ciphers list to RSA only in Client Hello
Thanks Dave. I could not find application explicitly calling SSL_set_cipher_list() anywhere and it seemed to be using new libraries. However as per your suggestion I am now setting the cipher list in the application before SSL_connect and it sends the desired ciphers. Thanks, Gauri On Wed, May 4, 2011 at 3:05 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Gauri Kshirsagar Sent: Tuesday, 03 May, 2011 05:37 I have built an SIP test application using openssl. I am trying to restrict the ciphers sent by this application in Client Hello to those with only RSA key exchange. Is there a way to configure it in OpenSSL? I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST set to RSA:!aNULL:!eNULL:+RC4:@STRENGTH in ssl.h. !aNULL after (only) RSA is a no-op. When I run openssl ciphers -v the ciphers listed are just those with RSA, C:\Openssl_src\openssl-0.9.8f\openssl-0.9.8f\out32dllopenssl.exe ciphers -v snip but when I build the application using these new libraries the application still sends all the ciphers as shown below snip 1. Make sure the application *runs* with your modified DLL(s). On Unix the equivalent is explicit, but IME most Windows versions formerly tried the executable's directory first and then PATH but recent Windows security patches apparently changed this. 2. The default is only the default. If the application calls SSL_[CTX_]set_cipher_list that overrides. Unless you have a reason to make this change across your entire system (or network) it's usually better for each application to configure its own cipherlists than have 3 or 5 or 20 different OpenSSLs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Restricting ciphers list to RSA only in Client Hello
Hi All, I have built an SIP test application using openssl. I am trying to restrict the ciphers sent by this application in Client Hello to those with only RSA key exchange. Is there a way to configure it in OpenSSL? I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST set to RSA:!aNULL:!eNULL:+RC4:@STRENGTH in ssl.h. When I run openssl ciphers -v the ciphers listed are just those with RSA, C:\Openssl_src\openssl-0.9.8f\openssl-0.9.8f\out32dllopenssl.exe ciphers -v AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export *but when I build the application using these new libraries the application still sends all the ciphers as shown below* Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x35) Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a) Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) Cipher Spec: TLS_RSA_WITH_IDEA_CBC_SHA (0x07) Cipher Spec: SSL2_IDEA_128_CBC_WITH_MD5 (0x050080) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x05) Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x04) Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15) Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x12) Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x09) Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14) Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x11) Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x08) Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x06) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x03) Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) Do I need to do anything else to restrict the cipher list to RSA only? Regards, Gauri
Re: Restricting ciphers list to RSA only in Client Hello
Hi All, I have built an SIP test application using openssl. I am trying to restrict the ciphers sent by this application in Client Hello to those with only RSA key exchange. Is there a way to configure it in OpenSSL? I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST set to RSA:!aNULL:!eNULL:+RC4:@STRENGTH in ssl.h. When I run openssl ciphers -v the ciphers listed are just those with RSA, C:\Openssl_src\openssl-0.9.8f\openssl-0.9.8f\out32dllopenssl.exe ciphers -v AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export but when I build the application using these new libraries the application still sends all the ciphers as shown below Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x35) Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a) Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) Cipher Spec: TLS_RSA_WITH_IDEA_CBC_SHA (0x07) Cipher Spec: SSL2_IDEA_128_CBC_WITH_MD5 (0x050080) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x05) Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x04) Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15) Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x12) Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x09) Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14) Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x11) Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x08) Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x06) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x03) Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) Do I need to do anything else to restrict the cipher list to RSA only? Regards, Gauri Hi, Can you paste here the source code? I would like to see your implementation. Regards - Дизайнерски обувки с до -70%. Регистрирай се и пазарувай. http://clk.tradedoubler.com/click?p=191500a=1875689g=19425934
Re: Restricting ciphers list to RSA only in Client Hello
Won't be able to paste the entire source code since the SIP application
uses SipXces stack. SipStack has been built with open ssl which calls
SSL_connect as shown below
void OsSSLConnectionSocket::SSLInitSocket(int socket, long timeoutInSecs)
{
if (mIsConnected)
{
int err = -1;
// TODO: eventually this should allow for other SSL contexts...
mSSL = OsSharedSSL::get()-getServerConnection();
if (mSSL (socketDescriptor OS_INVALID_SOCKET_DESCRIPTOR))
{
SSL_set_fd (mSSL, socketDescriptor);
err = SSL_connect(mSSL);
Any pointers that you think I could verify from my end would be helpful.
Thanks and Regards,
Gauri
On Tue, May 3, 2011 at 10:42 AM, derleader mail derlea...@abv.bg wrote:
Hi All,
I have built an SIP test application using openssl. I am trying to restrict
the ciphers sent by this application in Client Hello to those with only RSA
key exchange.
Is there a way to configure it in OpenSSL?
I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST set to
RSA:!aNULL:!eNULL:+RC4:@STRENGTH in ssl.h.
When I run openssl ciphers -v the ciphers listed are just those with RSA,
C:\Openssl_src\openssl-0.9.8f\openssl-0.9.8f\out32dllopenssl.exe ciphers
-v
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
IDEA-CBC-MD5SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5
EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1
export
EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5
export
EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5
export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5
export
EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5
export
*but when I build the application using these new libraries the
application still sends all the ciphers as shown below*
Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38)
Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13)
Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)
Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32)
Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
Cipher Spec: TLS_RSA_WITH_IDEA_CBC_SHA (0x07)
Cipher Spec: SSL2_IDEA_128_CBC_WITH_MD5 (0x050080)
Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080)
Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x05)
Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x04)
Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)
Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15)
Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x12)
Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x09)
Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040)
Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14)
Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x11)
Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x08)
Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x06)
Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080)
Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x03)
Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080)
Do I need to do anything else to restrict the cipher list to RSA only?
Regards,
Gauri
Hi,
Can you paste here the source code? I would like to see your
implementation.
Regards
-
Дизайнерски обувки с до -70%. Регистрирай се и пазарувай.
http://a.abv.bg/www/delivery/ck.php?oaparams=2__bannerid=4884__zoneid=63__oadest=http://clk.tradedoubler.com/click?p=191500a=1875689g=19425934
RE: Restricting ciphers list to RSA only in Client Hello
From: owner-openssl-us...@openssl.org On Behalf Of Gauri Kshirsagar Sent: Tuesday, 03 May, 2011 05:37 I have built an SIP test application using openssl. I am trying to restrict the ciphers sent by this application in Client Hello to those with only RSA key exchange. Is there a way to configure it in OpenSSL? I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST set to RSA:!aNULL:!eNULL:+RC4:@STRENGTH in ssl.h. !aNULL after (only) RSA is a no-op. When I run openssl ciphers -v the ciphers listed are just those with RSA, C:\Openssl_src\openssl-0.9.8f\openssl-0.9.8f\out32dllopenssl.exe ciphers -v snip but when I build the application using these new libraries the application still sends all the ciphers as shown below snip 1. Make sure the application *runs* with your modified DLL(s). On Unix the equivalent is explicit, but IME most Windows versions formerly tried the executable's directory first and then PATH but recent Windows security patches apparently changed this. 2. The default is only the default. If the application calls SSL_[CTX_]set_cipher_list that overrides. Unless you have a reason to make this change across your entire system (or network) it's usually better for each application to configure its own cipherlists than have 3 or 5 or 20 different OpenSSLs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: VMS client ASN1 decoding error, was RE: Hello!
Dave may be right about there being no direct evidence for a read. However I have since looked at the code the error is coming from and the error is being reported at the time the SSL context is being interpreted, which doesn't mean the initial loading of the SSL context wasn't error free as it appears the context can be loaded erroneously without a complaint. If that is true and the error occurs at context parse time, then any conjecture we make about the actual cause of the error is purely conjecture. I apologize to irivas for jumping to conclusions initially and suggested offline to him that he get more information from tools like snoop/tcpdump and truss/strace that may or may not be available in openvms. The relevant information I gave to Irivas is this: The error he was getting comes from ssl/s3_clnt.c in the ssl3_get_server_certificate() function. When this function parses a message buffer it decides is a certificate chain and cannot decode the DER format of one of the certificate elements in the chain via the function d2i_X509(), then it emits the error Irivas sees. If you look at http://www.openssl.org/docs/crypto/d2i_X509.html you will see that it says that the reverse function i2d_X509() has bad error handling in some versions of openssl and can result in the creation of a bad structure for d2i_X509() to process later. By way of explanation openssl loads stuff into buffers first and processes it later. One last thing I hope the metadata of the openvms file structure doesn't get in the way of flat text processing. If a file is a different format to flat text, then you process it differently. The Windows/Unix text file nonsense is purely a disagreement about the end of line token and nothing to do with the file structure. On 6/10/2010 7:34 AM, Dave Thompson wrote: snip much and fix formatting 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! NOTE: SSL3_GET_SERVER_CERTIFICATE 1409000D F_SSL3_GET_SERVER_CERTIFICATE R_ASN1_LIB sure looks to me like parsing the wire message. If verification failed because it couldn't parse the store, that's 14090086 F_SSL3_GET_SERVER_CERTIFICATE R_CERTIFICATE_VERIFY_FAILURE with an error stack including at least 0B06F009. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected. -- G. K. Chesterton I must be a Progressive then :) -- J. T. Hunt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
You are reading files, see inline for discussion. On 5/10/2010 7:36 AM, irivas wrote: I don't even know where those errors come from. As I said before, the same code under Solaris runs alright. I'm only connecting to a regular webserver with ssl, nothing more, nothing less. I'm not consciously using anything other than plain http-- none of which is used up to that point. Calls made beforehand are: SSL_load_error_strings(); ERR_load_BIO_strings(); OpenSSL_add_all_algorithms(); ctx = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx is a SSL_CTX* See http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html If *CApath* is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the *c_rehash* utility to create the necessary links. The certificates in *CApath* are only looked up when required, e.g. when building the certificate chain or when actually performing the verification of a peer certificate. If you look at the error below it is reading the certificate file. Try running a filter like unix2dos on your certificate files, and probably your configuration files on your OpenVMS system. Your certificate files are flat ascii files. bio = BIO_new_ssl_connect(ctx);//bio is a BIO* BIO_get_ssl(bio,ssl); //ssl is a SSL* SSL_set_mode(ssl,SSL_MODE_AUTO_RETRY); BIO_set_conn_hostname(bio,buffer);//buffer is a string of the form host:portnumber Anything I should be doing? The error occurs immediately afterwards. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 4:15 PM To: openssl-users@openssl.org Subject: Re: Hello! ASN.1 encoding will require much more than a simple sprintf. If your resulting string is expected to be encoded in ASN.1, then there may be a problem there. Pierre Le 04/10/2010 22:02, irivas a écrit : To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! NOTE: SSL3_GET_SERVER_CERTIFICATE Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
VMS client ASN1 decoding error, was RE: Hello!
From: owner-openssl-us...@openssl.org On Behalf Of Jeremy Hunt Sent: Monday, 04 October, 2010 19:08 You are reading files, see inline for discussion. On 5/10/2010 7:36 AM, irivas wrote: SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx is a SSL_CTX* See http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html snip If you look at the error below it is reading the certificate file. I don't think so. Try running a filter like unix2dos on your certificate files, and probably your configuration files on your OpenVMS system. Your certificate files are flat ascii files. I agree this could be *another* issue when he does get to verifying. Note that VMS files don't have *just* NL or CRLF; they have additional attributes (metadata) like STREAM WITH CARRIAGE CONTROL. I don't know exactly what attributes are needed/allowed for files read by C stdio, which OpenSSL uses, but whatever they are should be done. (This is the same general category as unix2dos but quite different in detail.) His application doesn't appear to be using openssl.conf. If the app has its own config data he has presumably dealt with that already before getting to the point of calling OpenSSL routines. snip much and fix formatting 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! NOTE: SSL3_GET_SERVER_CERTIFICATE 1409000D F_SSL3_GET_SERVER_CERTIFICATE R_ASN1_LIB sure looks to me like parsing the wire message. If verification failed because it couldn't parse the store, that's 14090086 F_SSL3_GET_SERVER_CERTIFICATE R_CERTIFICATE_VERIFY_FAILURE with an error stack including at least 0B06F009. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Hello!
Hello everyone! My name's Irving and I'm new to openssl. I'm having an issue and I hope I can get help here. I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? I tried googling and searching the mailing list archive, but didn't find any pointers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
On Mon October 4 2010, irivas wrote: Hello everyone! My name's Irving and I'm new to openssl. I'm having an issue and I hope I can get help here. I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? Mike I tried googling and searching the mailing list archive, but didn't find any pointers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Hello!
I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Hello!
To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello!
ASN.1 encoding will require much more than a simple sprintf. If your resulting string is expected to be encoded in ASN.1, then there may be a problem there. Pierre Le 04/10/2010 22:02, irivas a écrit : To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Hello!
I don't even know where those errors come from. As I said before, the same code under Solaris runs alright. I'm only connecting to a regular webserver with ssl, nothing more, nothing less. I'm not consciously using anything other than plain http-- none of which is used up to that point. Calls made beforehand are: SSL_load_error_strings(); ERR_load_BIO_strings(); OpenSSL_add_all_algorithms(); ctx = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx is a SSL_CTX* bio = BIO_new_ssl_connect(ctx);//bio is a BIO* BIO_get_ssl(bio,ssl); //ssl is a SSL* SSL_set_mode(ssl,SSL_MODE_AUTO_RETRY); BIO_set_conn_hostname(bio,buffer);//buffer is a string of the form host:portnumber Anything I should be doing? The error occurs immediately afterwards. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 4:15 PM To: openssl-users@openssl.org Subject: Re: Hello! ASN.1 encoding will require much more than a simple sprintf. If your resulting string is expected to be encoded in ASN.1, then there may be a problem there. Pierre Le 04/10/2010 22:02, irivas a écrit : To further clarify: The error is a result of a call to BIO_do_connect(); Prior to that call, I make a call to sprintf(%s:%d); (no newlines involved). I'll try substituting the sprintf for a more ubiquitous process and let you know. Any further ideas on the matter? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE Sent: Monday, October 04, 2010 3:25 PM To: openssl-users@openssl.org Subject: Re: Hello! I do not know anything about OpenVMS and Solaris, BUT big endian / little endian and improper use of htons in YOUR software could explain many things. You should check also \r and \r \n issue, even if not reading any file, because it may be in cause in fprintf(fd, \n); \n being expanded differently on some platforms. Hope this may help, Pierre Le 04/10/2010 21:09, irivas a écrit : I have a tiny software written to communicate with an http server; on a Solaris system it works alright, but on an OpenVMS system I'm getting these errors: 545318540:error:0D07809F:asn1 encoding routines:ASN1_ITEM_EX_D2I:unexpected eoc:TASN_DEC:337:Type=X509_ALGOR 545318540:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 error:TASN_DEC:566:Field=sig_alg, Type=X509 545318540:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:S3_CLNT:816:$! Any ideas? Where and what should I look for to fix this? First thought - line endings. At least with local text file storage, OpenVMS provides cr-lf on reads. Solaris uses lf Could this somehow be related to your problem over-the-wire? I don't really think so -- I'm not reading from any files at the point this error occurs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
VMS client ASN1 decoding error, was RE: Hello!
From: owner-openssl-us...@openssl.org On Behalf Of irivas Sent: Monday, 04 October, 2010 16:36 (I changed the subject to be more descriptive.) I don't even know where those errors come from. As I said before, the same code under Solaris runs alright. I'm only connecting to a regular webserver with ssl, nothing more, nothing less. I'm not consciously using anything other than plain http-- none of which is used up to that point. Calls made beforehand are: SSL_load_error_strings(); ERR_load_BIO_strings(); Aside: this is redundant. SSL_load_error_strings includes ERR_load_crypto_strings which includes all active modules which includes BIO. But it does no harm. OpenSSL_add_all_algorithms(); ctx = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx is a SSL_CTX* I assume foldername (without the stray ) is a VMS directory, which to my recollection doesn't have folders. Does the rehash procedure or an equivalent work on VMS, and was it done here? If not, that will cause verification errors later (but at present you're not even getting to verification). bio = BIO_new_ssl_connect(ctx);//bio is a BIO* BIO_get_ssl(bio,ssl); //ssl is a SSL* SSL_set_mode(ssl,SSL_MODE_AUTO_RETRY); BIO_set_conn_hostname(bio,buffer);//buffer is a string of the form host:portnumber Anything I should be doing? The error occurs immediately afterwards. Unless the webserver is selectively misencoding, which seems very unlikely, there may be a problem with ASN.1 decoding, or possibly TCP/IP (but I hope not). I should warn you there doesn't seem to be nearly as much usage of OpenSSL on VMS as on various Unices, Windows, and I think even Mac. It's possible bugs got into at least some version(s), although a problem in something as basic as this seems unlikely. I used VMS a little long ago, but not with OpenSSL or even TCP/IP. What version of OpenSSL are you using, and did you build it or who did and how? If you have the commandline aka monolith available (I hope you do), do version -a. (On Unix you can give this on the command line like /path/to/openssl version -a, but on VMS you may need to do it interactively, I'm not sure.) Also in commandline, try s_client -connect server:port -msg (and if it connects, immediately give it EOF or interrupt). This will confirm where the failed operation is occurring, and show the data it's using for manual inspection. Note this will probably produce many screenfuls of data; I vaguely recall there is a way to capture it with something like SET /LOG, or perhaps the terminal emulator you are using can log. You might also do /path/openssl s_client -connect ... from the good (Solaris) system for comparison. As an additional data point for ASN.1, if you have a known good certificate file -- and anything you put in your verify_location (trust) directory should have been known good -- do commandline x509 -in certfile -noout and check it doesn't give an error, and x509 -in certfile -noout -text displays lots of info. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Hello All Once Again
This time my question isn't out of necessity, but rather curiosity. I've been playing around with calculating the Session Key, and the IV for an SSL connection for a man-in-the-middle type proxy, and finally stumbled upon the EVP_CIPHER_ctx module. Inside of this struct there are two data members: unsigned char oiv[EVP_MAX_IV_LENGTH] and unsigned char iv[EVP_MAX_IV_LENGTH]. Oiv is the original IV, and IV is the current IV. I've been playing around with these two datum, and it seems to me that they never change throughout the lifetime of the application. Is this normal behavior? or should the be rather unpredictably random. The way I am calculating the vector does not rely on this data, so it's neither here nor there, but it did strike me as odd. If anyone has any comments, or input I would like to hear what is really going on here. Looking forward to responses, Sam -- Sam Jantz Software Engineer
