Re: connection problem with the version 1.0.1e
Rajesh Malepati wrote
On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;
kirpit@
gt; wrote:
The server doesn't seem to care to respond to clients supporting TLS 1.2
ok:
openssl s_client -tls1 -connect emea.webservices.travelport.com:443
no reply:
openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443
such servers should be beaten to pulp.
Hi,
I ran into the same problem and then came across this thread. According to
http://tools.ietf.org/html/rfc5246#appendix-E:
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number.
Why then the server isn't responding at all to the Client Hello for TLS1.2?
Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
need to be fixed as it is not compliant with the RFC.
--
View this message in context:
http://openssl.6102.n7.nabble.com/connection-problem-with-the-version-1-0-1e-tp45935p46868.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: connection problem with the version 1.0.1e
nehakochar wrote Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would need to be fixed as it is not compliant with the RFC. Correction: I am not sure if it is 1.0.1e that is the problematic version. But would like to know if this is expected behavior (although incorrect) with OpenSSL, and if yes, is it true for all versions (including 1.0.1e)? -- View this message in context: http://openssl.6102.n7.nabble.com/connection-problem-with-the-version-1-0-1e-tp45935p46869.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
Query related to d2i_X509 and X509_free
Hi,
We are using openssl-1.0.0e. I am facing a memory leak of 98 bytes when I
use d2i_X509() function. This memory leak is seen even if d2i_X509() return
NULL. I couldn't find the source code for d2i_X509() and X509_free()
function. Can you please help me in this.
int secwrap_certCheckExtKeyUsage(unsigned char *cert, // pointer to
certificate
unsigned int certLen) // length of
certificate
{
intiReturnStatus = OPENSSL_SECWRAP_FAILURE, iCritical;
X509 *x509Cert = NULL;
const unsigned char *pCert = cert; // See OpenSSL
FAQ. Temp pointer recommended.
EXTENDED_KEY_USAGE *extusage = NULL;
int count;
if(cert == NULL || certLen == 0)
{
DEBUGPRINT(DEBUG_DEFAULT,%s - %d FAIL\n,__FUNCTION__,__LINE__);
return OPENSSL_SECWRAP_FAILURE; // bad
parameters
}
x509Cert = d2i_X509(NULL, pCert, certLen);
if(x509Cert == NULL)
{
DEBUGPRINT(DEBUG_DEFAULT,%s - %d FAIL\n,__FUNCTION__,__LINE__);
return OPENSSL_SECWRAP_FAILURE; // unable to
parse cert
}
count = X509_get_ext_count(x509Cert);
if(count == 1) // only 1 extension allowed
{
extusage = (EXTENDED_KEY_USAGE *) X509_get_ext_d2i(x509Cert,
NID_ext_key_usage, iCritical, NULL);
if(extusage != NULL iCritical != 0) // MUST be
Extended Key Usage and marked critical
{
if(sk_ASN1_OBJECT_num(extusage) == 1) // only 1
purpose OID allowed
{
if(OBJ_obj2nid(sk_ASN1_OBJECT_value(extusage,0)) ==
NID_code_sign)// MUST be for code signing
{
iReturnStatus = OPENSSL_SECWRAP_SUCCESS;
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,%s - %d
FAIL\n,__FUNCTION__,__LINE__);
}
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,%s - %d
FAIL\n,__FUNCTION__,__LINE__);
}
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,%s - %d
FAIL\n,__FUNCTION__,__LINE__);
}
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,%s - %d FAIL count
%d\n,__FUNCTION__,__LINE__,count);
}
if(x509Cert != NULL)
X509_free(x509Cert);
return iReturnStatus;
}
Regards,
Sandeepa Sharma
Re: Abort after free() of non-allocated pointer
FYI: it's hard to believe the error is on the OpenSSL side (the
software shows timing errors (the way i use it at least), and
these are always handled properly by the OpenSSL layer), but
i have nonetheless added a 'debug-darwin64-x86_64-cc' to
'Configure' and got some debug libraries (
206984 -rw-r--r--1 steffen staff 211951296 11 Oct 13:18 libcrypto.a
26808 -rw-r--r--1 steffen staff 27450488 11 Oct 13:20 libssl.a
) to link against. Shall this error occur again (it was the
second time i saw it) then i will (hopefully) be able to provide
better information.
Ciao,
--steffen
---BeginMessage---
Hello! Am i right here?
It's actually hard to believe the error is on the OpenSSL side,
and i definetely should look deeper before sending this, but on
the other hand this is so deep down in the OpenSSL code...
?0[steffen@sherwood src]$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
?0[steffen@sherwood src]$ otool -L ~/usr/bin/s-nail
/Users/steffen/usr/bin/s-nail:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version
7.0.0)
/Users/steffen/usr/lib/libssl.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/Users/steffen/usr/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/Users/steffen/usr/lib/libidn.11.dylib (compatibility version 18.0.0,
current version 18.10.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.11)
?0[steffen@sherwood src]$ ll ~/usr/lib/*ssl*
4 lrwxrwxr-x 1 steffen staff 18 15 Feb 2013
/Users/steffen/usr/lib/libssl.dylib@ - libssl.1.0.0.dylib
596 -rw-r--r-- 1 steffen staff 609480 15 Feb 2013
/Users/steffen/usr/lib/libssl.a
444 -r-xr-xr-x 1 steffen staff 452952 15 Feb 2013
/Users/steffen/usr/lib/libssl.1.0.0.dylib*
...
T1135 OK Returned to authenticated state. (Success)
T1136 LOGOUT
* BYE LOGOUT Requested
s-nail(20015) malloc: *** error for object 0x1004beb00: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted.
0x7fff824df0b6 in __kill ()
(gdb) bt
#0 0x7fff824df0b6 in __kill ()
#1 0x7fff8257f9f6 in abort ()
#2 0x7fff82497195 in free ()
#3 0x0001000f61f5 in CRYPTO_free ()
#4 0x00010019bcdc in ASN1_primitive_free ()
#5 0x00010019c0bc in ASN1_template_free ()
#6 0x00010019bfbf in asn1_item_combine_free ()
#7 0x00010019c0bc in ASN1_template_free ()
#8 0x00010019bfbf in asn1_item_combine_free ()
#9 0x00010019c0f7 in ASN1_item_free ()
#10 0x0001000b7b80 in SSL_SESSION_free ()
#11 0x0001000b49e5 in SSL_free ()
#12 0x000100014519 in sclose ()
-
#ifdef HAVE_OPENSSL
if (sp-s_use_ssl) {
sp-s_use_ssl = 0;
SSL_shutdown(sp-s_ssl);
SSL_free(sp-s_ssl);
sp-s_ssl = NULL;
SSL_CTX_free(sp-s_ctx);
sp-s_ctx = NULL;
}
#endif
-
#13 0x00010001c46e in imap_exit ()
#14 0x00010001bd10 in imap_quit ()
warning: Could not open object file: /Users/steffen/src/nail.git/quit.o: No
such file or directory
warning: Couldn't open object file '/Users/steffen/src/nail.git/quit.o'
#15 0x00010003daed in quit ()
#16 0x0001000274ea in setfile ()
#17 0x0001cd90 in cfile ()
#18 0x000100028fb8 in execute ()
#19 0x0001000286ed in commands ()
#20 0x00010002fd6b in main ()
(gdb) ?
I hate debuggers and thus i am somewhat lost at this point, but if
there is something i can do, please let me know.
Thank you and ciao,
--steffen
---End Message---
Re: [openssl-users] Re: connection problem with the version 1.0.1e
Bonjour,
Le 11/10/2013 03:35, nehakochar a écrit :
Rajesh Malepati wrote
On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;
kirpit@
gt; wrote:
The server doesn't seem to care to respond to clients supporting TLS 1.2
ok:
openssl s_client -tls1 -connect emea.webservices.travelport.com:443
no reply:
openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443
such servers should be beaten to pulp.
Hi,
I ran into the same problem and then came across this thread. According to
http://tools.ietf.org/html/rfc5246#appendix-E:
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number.
Why then the server isn't responding at all to the Client Hello for TLS1.2?
Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
need to be fixed as it is not compliant with the RFC.
The server and client are both compliant.
With the first command, you tell the client to use TLS1.0 only. No more,
no less. The server is ok with it, and both negociate TLS1.0.
With the second command, you tell the client to use TLS1.2 only, again
no more no less. The server receives a TLS1.2 negociation, replies with
a TLS1.0 server hello message, and the client refuses it, cleanly
(because you told it to do so).
If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2
-no_ssl3 options instead.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL OCSP
Hi, Could you please tell me how to do the set up of local ocsp responder as you did it like http://ocsp_responder:3456.? Its really urgent and time is less. -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-OCSP-tp15350p46874.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
Best practices guidance for using OpenSSL to make cetificate authorities
I found a Linux FAQ dealing with this subject, but it is very dated (11.5 years old) and I do not know how much has changed since it was last updated. While I am a programmer, I am looking only to use openssl to make the certificates and keys I need, and not to create new programs using openssl (unless in the course of my studyign the use of openssl, I find I need to write some custom code). Here is what I want to do. I want to create a certificate authority to make certificates for a couple of my web servers, for the purpose of having support for HTTPS, and if possible sign selected documents that are then served to the user's browser (just those I selected, not all by any means); with the ability to let the user download the certificate to let him trust the server afterwards. I also want to support creating client side certificates that support encrypting and signing emails and form data on web pages (to support non-repudiation, with the assurance that the signed document was not altered since it was signed). None of the certificates I need need support for code signing. Do I need both root and non root CAs, or will a root CA suffice by itself. And where should the keys and certificates be placed on Ubuntu and Suse (I have both), and should I do all this as a normal user or as root (NB: I am still trying to learn anough about administering Linux that I can at least deal with the things I need to do on my Linux boxes, so it is OK to be a little pedantic)? I am a bit concerned about usability on the server as the FAQ I have been reading (actually one of the clearest I have seen even though it is old), since it says I should not remove the pass phrase from the certificate, but I would think that would make HTTPS unusable since it would ask the user for a password each time he asks for a resource from the server. At the same time, can I force a requirement that the client side certificates require a password that has a reasonable strength? If so, how? And for all this, will one opeenssl.cnf suffice, or do I have to make several? Finally, is there a good document or example that tells me not only what cofiguration options are available to enter in openssl.cnf, but what values will provide me with the best security for the longest period consistent with what is supported in the most commonly used browsers? Something that says something like 'This is X, and it is for Y, but do not touch it unless you know what you're doing', and yet provides no guidance for further reading so the user can learn what he needs to know about all of it, is not so useful for my purposes. NB: This is primarily for my own education. Thank you for your time. Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practices guidance for using OpenSSL to make cetificate authorities
This might be useful http://unmitigatedrisk.com/?p=194 Ryan Hurst Sent from my phone, please forgive the brevity. On Oct 12, 2013, at 12:53 AM, Ted Byers r.ted.by...@gmail.com wrote: I found a Linux FAQ dealing with this subject, but it is very dated (11.5 years old) and I do not know how much has changed since it was last updated. While I am a programmer, I am looking only to use openssl to make the certificates and keys I need, and not to create new programs using openssl (unless in the course of my studyign the use of openssl, I find I need to write some custom code). Here is what I want to do. I want to create a certificate authority to make certificates for a couple of my web servers, for the purpose of having support for HTTPS, and if possible sign selected documents that are then served to the user's browser (just those I selected, not all by any means); with the ability to let the user download the certificate to let him trust the server afterwards. I also want to support creating client side certificates that support encrypting and signing emails and form data on web pages (to support non-repudiation, with the assurance that the signed document was not altered since it was signed). None of the certificates I need need support for code signing. Do I need both root and non root CAs, or will a root CA suffice by itself. And where should the keys and certificates be placed on Ubuntu and Suse (I have both), and should I do all this as a normal user or as root (NB: I am still trying to learn anough about administering Linux that I can at least deal with the things I need to do on my Linux boxes, so it is OK to be a little pedantic)? I am a bit concerned about usability on the server as the FAQ I have been reading (actually one of the clearest I have seen even though it is old), since it says I should not remove the pass phrase from the certificate, but I would think that would make HTTPS unusable since it would ask the user for a password each time he asks for a resource from the server. At the same time, can I force a requirement that the client side certificates require a password that has a reasonable strength? If so, how? And for all this, will one opeenssl.cnf suffice, or do I have to make several? Finally, is there a good document or example that tells me not only what cofiguration options are available to enter in openssl.cnf, but what values will provide me with the best security for the longest period consistent with what is supported in the most commonly used browsers? Something that says something like 'This is X, and it is for Y, but do not touch it unless you know what you're doing', and yet provides no guidance for further reading so the user can learn what he needs to know about all of it, is not so useful for my purposes. NB: This is primarily for my own education. Thank you for your time. Ted __ 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: Increasing key size from 1024 to 2048?
Not so much. Factoring reached 768 several years ago, and the consensus seems to be that RSA-1024, and DSA and DH, is in danger within not too many years though not broken now. And it often takes months or years to get new crypto, or even new keys, fully deployed especially when you can't have a flag day, so it's as well to start moving now. Although technically 1536 would probably be enough for now, pretty much everyone seems to feel as long as we're changing let's do 2048. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Eric S. Eberhard Sent: Thursday, October 10, 2013 14:02 To: openssl-users@openssl.org Cc: int0...@safe-mail.net Subject: Re: Increasing key size from 1024 to 2048? Just curious -- what line of work is your company in? If you were CIA or NASA or something I'd see the need. If you are just a business -- wow! E On 10/10/2013 1:37 AM, int0...@safe-mail.net wrote: Hi, snip: as per subject
RE: [openssl-users] Re: connection problem with the version 1.0.1e
From: owner-openssl-users On Behalf Of Erwann Abalea Sent: Friday, October 11, 2013 08:49 Le 11/10/2013 03:35, nehakochar a écrit : Rajesh Malepati wrote On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;kirpit@gt; wrote: The server doesn't seem to care to respond to clients supporting TLS 1.2 snip I ran into the same problem and then came across this thread. According to http://tools.ietf.org/html/rfc5246#appendix-E: snip Why then the server isn't responding at all to the Client Hello for TLS1.2? Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would need to be fixed as it is not compliant with the RFC. The server and client are both compliant. With the first command, you tell the client to use TLS1.0 only. No more, no less. The server is ok with it, and both negociate TLS1.0. With the second command, you tell the client to use TLS1.2 only, again no more no less. The server receives a TLS1.2 negociation, replies with a TLS1.0 server hello message, and the client refuses it, cleanly (because you told it to do so). If the server responds with a lower version, yes the client refuses it when told to require higher. That's not what the OP described, or the earlier thread (and several others) said. They said *NOT ANY* response. I'm not sure about the particular thread cited here, but some threads said and experiment confirmed that s_client default (no versions required or prohibited) also failed the same way. That's broken, although it's arguably not actually noncompliant. 5246 can't impose requirements on a 4346 or 2246 implementation; note the old-server behavior is worded as 'will' while the 1.2-client handling of downrev is 2119 MUST (send alert 70). Neither earlier RFCs nor 5246 explicitly requires the server to handle ClientHello over about 256 bytes, which was observed to cause the problem, although since 3546 and 4346 it's known that this message can and does grow, and a competent implementation should handle that reasonably. If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2 -no_ssl3 options instead. 1.0.0+ defaults to SSL3/TLS format so it already won't succeed in negotiating SSL2 even if you don't explicitly -no_ssl2. But this doesn't help with broken servers. As long as 1.2 is enabled, OpenSSL client sends the longer ClientHello. You can use -no_tls1_2 to allow only lower versions, select a specific lower version, or restrict the cipherlist so that it shrinks the ClientHello small enough. And you should complain to the server operator(s) -- although if they're on old software and can't easily upgrade, that may not help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
