Re: cannot read PEM key file - no start line
On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall f...@sbcglobal.net wrote: I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB: 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line The cert file is the following: • DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem • WF Enterprise CA 02 certificate, signed by WF Root • WF Root certificate You should probably post the certificate somewhere so others can examine it. I was told by the support at MongoDB to do the following: § Copy the certificates into a text editor to ensure there is no whitespace § Ensure the beginning and end certificate statements are on there own line and have the same number of '-' at each end. § Ensure each line has 64 chars (except the last line) I don't believe OpenSSL has these restrictions. Are they MongoDB requirements? I have checked and verified that there is no whitespace. Also, the BEGIN and END statements look correct. However, each line in the cert is 76 chars in length, except for the last line. Should the lines be 64-characters long? The following will tell you if the problem is with the certificate or lies elsewhere. openssl x509 -in ...bank.corp_mongo_wells.pem -inform PEM -text -noout You can also try -inform DER if the certificate is ASN.1/DER encoded. If it is, then convert it from DER to PEM. If you can dump the certificate, then the certificate is probably OK and the problem likely lies elsewhere. Jeff
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 0:04 GMT+02:00 Kyle Hamilton aerow...@gmail.com: To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest? Not a big expert in these subjects, but a workaround coming to my mind is the following: - Prefix ALL the OpenSSL symbols with the OPENSSL_ prefix. - Include a m4 replacement in the whole source code of openssl with a compiler --enable-global-prefix option to enable or disable it. This is, when disabled the OPENSSL_ prefix becomes an empty string and nothing changes. - By default the compiler option is disabled, but the project announces this feature and encourages people to enable it and update their projects. - At some time the option becomes enabled by default. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 1:15 GMT+02:00 Pierre DELAAGE delaage.pie...@free.fr: Switch strongly and definitely to C++ Not for fancy object programming, but for more practical syntaxES for things like this. I do code in C++, but I need some C libraries. Regardless my C++ code is properly namespaced I don't like to see so many global C symbols in it. As I said before, in my case I integrate openssl and libsrtp C libraries into my C++ project. It 's annoying for me to see that the macro SRTP_PROTECTION_PROFILE (which I need in my project) is defined by openssl rather than libsrtp. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 3:52 GMT+02:00 Jakob Bohm jb-open...@wisemo.com: And how would you do that without breaking compatibility with every program (in C, C++ or any other language) that already uses openssl and depends on the current API names? That's the show-stopper rationale. I expect that old projects relying on OpenSSL should be adapted at some time, otherwise OpenSSL may provide backward compatibility updates (as it does now). But at some point bugs must be fixed and, IMHO, the namespace/prefix pollution of OpenSSL is a bug. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: cannot read PEM key file - no start line
On Sun, Sep 07, 2014 at 07:26:05PM -0700, Liz Fall wrote: I have checked and verified that there is no whitespace. Also, the BEGIN and END statements look correct. However, each line in the cert is 76 chars in length, except for the last line. Should the lines be 64-characters long? Yes. The OpenSSL base64 decoder limits input lines to 64 characters. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to empty a BIO buffer?
Hi, I'm trying to avoid a BIO_read() call given that it copies the BIO buffer data into a buffer I must provide to the function. I use a BIO memory pair. In my case it would be nice if I can get the pointer and length of the current BIO buffer and then tell the BIO to empty/clean it. So I want to replace this code: -- int read = BIO_read(sslBioToNetwork, (void*)myBuffer, MY_BUFFER_SIZE); // Use the read data -- with something like this: --- long read; char** data = (char**)myBuffer; read = BIO_get_mem_data(sslBioToNetwork, data); // Emtpy the BIO buffer data, HOW? // Use the read data --- But I do not know how to empty the already read BIO buffer data. BIO_flush() does nothing. How may I do this? Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
There seems to be some misunderstanding : My original answer was not directed to you, but to Kyle who was asking for suggestions to solve your pb. My suggestion is indeed that openssl lib switch to C++, at least for namespace usage. that will solve your problem with very limited -or no- impact on other apps. Le 08/09/2014 14:13, Iñaki Baz Castillo a écrit : 2014-09-08 1:15 GMT+02:00 Pierre DELAAGE delaage.pie...@free.fr: Switch strongly and definitely to C++ Not for fancy object programming, but for more practical syntaxES for things like this. I do code in C++, but I need some C libraries. Regardless my C++ code is properly namespaced I don't like to see so many global C symbols in it. As I said before, in my case I integrate openssl and libsrtp C libraries into my C++ project. It 's annoying for me to see that the macro SRTP_PROTECTION_PROFILE (which I need in my project) is defined by openssl rather than libsrtp. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
My suggestion is indeed that openssl lib switch to C++, at least for namespace usage. That would be nice to have. But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :) I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz
RE: Why does OpenSSL own all the prefixes in the world?
While OpenSSL's namespace polution is certainly a problem - and a problem that was (in general) widely discussed in the C programming community at least as far back as the late 1980s - it's worth noting that it's a widespread issue that affects pretty much all languages of C's generation and earlier, and many application libraries. For example, SGI's original GL library contained external identifiers like c3d, which clearly stomped all over the namespace with unexpected collisions. Even today's OpenGL 4, which uses a gl prefix for some identifiers, has things like any - conceivably something an application would use. Of course there are historical reasons, chiefly to do with limited resources and concommittant limitations in OS tooling. The original C standard (ISO9989-1990) only required implementations to recognize 31 significant characters in an internal identifier - which certainly limits the scope for namespace prefixes - and only *6* characters for an external identifier, which all but rules them out. (The implementation can also treat external identifiers as case-insensitive for linking purposes.) There is no good solution to this. m4 preprocessing is not available (by default) on all OpenSSL platforms, and is fraught with complications, as is any other preprocessing solution: it complicates debugging, for example, and has to handle various complicated cases such as an apparent or actual identifier in quoted strings, macro expansions, and the like. Implementing an optional namespace using C preprocessor tricks such as token-pasting is an infeasible effort and similarly fraught. Moving to C++ breaks binary compatibility (due to name-mangling, etc), requires a new build system, likely breaks some supported platforms, and runs the risk of introducing failures due to the many differences between C and C++ - and it does nothing for macro names. (In general, compiling C as C++ is a Bad Idea, despite the claims of C++ proponents.) What *is* feasible is wrapping OpenSSL in a library that provides the functionality your application needs, and imposes the namespace protections you want (along with any enhanced functionality, etc), while hiding OpenSSL's symbols (by not exporting the external linkage symbols and not exposing the macros to the application). That's what we do. Few applications will use all, or even most, of OpenSSL's public functionality directly anyway. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Kyle Hamilton Sent: Sunday, 07 September, 2014 18:04 To: openssl-users@openssl.org; Iñaki Baz Castillo Subject: Re: Why does OpenSSL own all the prefixes in the world? The reason is legacy. Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities. To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest? -Kyle H On September 7, 2014 1:30:11 PM PST, Iñaki Baz Castillo i...@aliax.netmailto:i...@aliax.net wrote: Hi, RAND_xxx CRYPTO_xxx ERR_xxx ENGINE_xxx EVP_xxx sk_xxx X509_xxx BIGNUM_xxx RSA_xxx BN_xxx ASN1_xxx EC_xxx etc etc etc. May I understand why it was decided that OpenSSL can own all the prefixes or namespaces in the world? How is it possible that OpenSSL owns the ERR_ prefix (for example ERR_free_strings() and others)? OpenSSL is a library. I should be able to integrate OpenSSL into my own code and define my own prefixes without worrying about creating conflicts with the near 200 prefixes that OpenSSL owns. An example of a well designed C library is libuv [*], in which: * Public API functions and structs begin with uv_. * Private API functions begin with uv__. * Public macros begin UV_. That's a good design! PS: In my project I use both openssl and libsrtp. In which of t! hem do you expect the following macro is defined?: SRTP_PROTECTION_PROFILE [*] https://github.com/joyent/libuv/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. This message has been scanned for malware by Websense. www.websense.com
Re: cannot read PEM key file - no start line
On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall f...@sbcglobal.net wrote: I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB: 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line The cert file is the following: Cert file or key file? The error indicates that the client can't find the private key. free from viruses and malware because avast! Antivirus protection is active. Thanks for that amusing bit of insight. - M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
2014-09-08 14:44 GMT+02:00 Iñaki Baz Castillo i...@aliax.net: -- int read = BIO_read(sslBioToNetwork, (void*)myBuffer, MY_BUFFER_SIZE); // Use the read data -- with something like this: --- long read; char** data = (char**)myBuffer; read = BIO_get_mem_data(sslBioToNetwork, data); // Emtpy the BIO buffer data, HOW? // Use the read data --- But I do not know how to empty the already read BIO buffer data. BIO_flush() does nothing. Sorry, BIO_flush() works. The problem is that calling BIO_eof() after BIO_flush() does not return 1 so I get a loop. Updated my code not to check BIO_eof() after BIO_flush(). -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
This is why I just mentioned namespaces...
Le 08/09/2014 14:57, Salz, Rich a écrit :
My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.
That would be nice to have. But C++ classes are like opinions -- everyone has
one, nobody wants to use anyone else's. :)
I'd be surprised if OpenSSL started work on this, but I'd encourage interested
folks to work on it.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��IϮ��r�m
(���Z+�K �+1���x ��h���[�z�(���Z+� ��f�y����� �f���h��)z{,��
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
If all you want is C++ namespaces,could you you wrap the #include lines for
OpenSSL in a namespace declaration? (I am not a C++ guy, I honestly don't know
where problems would exist... except the namespaces don't do anything for
#define, I think?)
namespace openssl {
#include ssl/whatever.h
};
Another alternative might be to not mix code that relies on defined symbols
from one library in the same source file as one which requires a different
library with conflicting definitions. This would require passing context
structs to functions in different source files, with those functions doing what
needed to happen at that moment using the facilities available to that source
file.
A bigger problem is that it would necessarily change the ABI to dictate that
the symbols in the linked library cannot be linked as extern C.
Perhaps a compatibility library that forwards old-API calls to a namespaced
library could work... but the problem there is that there are platforms still
in use that likely have only limited C++ support. (Such as Amiga and OS/2.)
It's not an easy problem to address, and every option has compromises.
-Kyle H
On September 7, 2014 9:44:44 PM PST, Pierre DELAAGE delaage.pie...@free.fr
wrote:
At a time or another,
of course there would be some (hopefully limited) rewrite in apps :
not necessarily complicated: I was thinking about C++ namespaces.
It is also possible to offer to apps maintainers a global grep and
replace script, based on ed or vi in an automated way,
to replace every BIO_xxx by, eg, OSSL_BIO_xxx in all files in some
location.
Not so difficult either.
From year to year, It would be strange that openssl is maintaining, by
huge effort, various versions of the library (I mean for any given
platform, whatever it is),
just to avoid that old apps be maintained themselves doing lesser
effort.
I do not see so big problems with that, provided that, apart from
adapting some code, people are NOT pushed to buy, to pay, to invest, to
migrate to other platform (a strategy that many OS vendors have).
If there is a switch to C++ one day, and/or a change in the API design,
there can be a kind of progressive switching period where two api's
coexist,
one giving wrappers/redirectors to the other, or one being built on top
of the other, encapsulating it and -later- making the other NOT
public
and then maybe completely disappearing .
It would be interesting, in that perspective, to have some statistics
about the API functions REALLY in use in apps.
By some smart greps scripts that could be part of the openssl distrib
(so that people avoid to reinvent the wheel and all use the same tool
for such measurements).
Le 08/09/2014 03:52, Jakob Bohm a écrit :
And how would you do that without breaking compatibility with every
program (in C, C++ or any other language) that already uses openssl
and
depends on the current API names?
Providing the API, semantics and portability of the original SSLeay
library is thesecond-most important feature of OpenSSL (right after
actually being a secure SSL/TLSimplementation when used correctly).
On 08/09/2014 01:15, Pierre DELAAGE wrote:
Hmm...
Switch strongly and definitely to C++
Not for fancy object programming, but for more practical syntaxES
for
things like this.
And I am an old C fan programmer...
Pierre Delaage
Le 08/09/2014 00:04, Kyle Hamilton a écrit :
The reason is legacy. Eric Young was not conscious of namespace
pollution when he implemented SSLeay; since then, even after the
migration to the OpenSSL name and team, the focus has been more on
maintaining source compatibility than in creating new
interoperability opportunities.
To meet the goal of interoperability while enabling an alternate
symbolic namespace, what would you suggest?
-Kyle H
On September 7, 2014 1:30:11 PM PST, Iñaki Baz Castillo
i...@aliax.net wrote:
Hi,
RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx
etc etc etc.
May I understand why it was decided that OpenSSL can own all
the
prefixes or namespaces in the world? How is it possible that
OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and
others)?
OpenSSL is a library. I should be able to integrate OpenSSL
into my
own code and define my own prefixes without worrying about
creating
conflicts with the near 200 prefixes that OpenSSL owns.
An example of a well designed C library is libuv [*], in which:
* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.
That's a good design!
PS: In my project I use both openssl and libsrtp. In which of
them
do
you expect the following macro is defined?:
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/
Enjoy
Jakob
Re: Why does OpenSSL own all the prefixes in the world?
Breaking compatibilty with old apps will occur at a time : dixit the roadmap : Review and revise the public API with a view to reducing complexity (Timescale: Within one year) I suppose that reducing complexity will lead to some rewrites, elimination/merging some functions... So it will be the right time to bring some improvements such as C++ namespaces support, or even macro renaming, and breaking binary compatibility is not really a so big issue : at a time, if something is rewritten with efficiency and simplicity in mind, and robustness, it has to be promoted, pushed to replace past versions. and binary compatibility is already an issue : this is why there are so many version of openssl, too many to my mind, so that smart resources of the team are dispersed to redo and redo again (backporting or forward porting) all the time the same work. Anyway, on the short term, for an app maintainer : it is a fact that a solution to the prefixes mess can be to encapsulate openssl in a custom lib, hiding anything from the original lib to the external world. Pierre Le 08/09/2014 03:52, Jakob Bohm a écrit : And how would you do that without breaking compatibility with every program (in C, C++ or any other language) that already uses openssl and depends on the current API names? Providing the API, semantics and portability of the original SSLeay library is thesecond-most important feature of OpenSSL (right after actually being a secure SSL/TLSimplementation when used correctly). On 08/09/2014 01:15, Pierre DELAAGE wrote: Hmm... Switch strongly and definitely to C++ Not for fancy object programming, but for more practical syntaxES for things like this. And I am an old C fan programmer... Pierre Delaage Le 08/09/2014 00:04, Kyle Hamilton a écrit : The reason is legacy. Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities. To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest? -Kyle H On September 7, 2014 1:30:11 PM PST, Iñaki Baz Castillo i...@aliax.net wrote: Hi, RAND_xxx CRYPTO_xxx ERR_xxx ENGINE_xxx EVP_xxx sk_xxx X509_xxx BIGNUM_xxx RSA_xxx BN_xxx ASN1_xxx EC_xxx etc etc etc. May I understand why it was decided that OpenSSL can own all the prefixes or namespaces in the world? How is it possible that OpenSSL owns the ERR_ prefix (for example ERR_free_strings() and others)? OpenSSL is a library. I should be able to integrate OpenSSL into my own code and define my own prefixes without worrying about creating conflicts with the near 200 prefixes that OpenSSL owns. An example of a well designed C library is libuv [*], in which: * Public API functions and structs begin with uv_. * Private API functions begin with uv__. * Public macros begin UV_. That's a good design! PS: In my project I use both openssl and libsrtp. In which of them do you expect the following macro is defined?: SRTP_PROTECTION_PROFILE [*]https://github.com/joyent/libuv/ Enjoy Jakob __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate pass phrase brute force...
OK, that clarifies the situation and your question. It's impossible to provide a specific answer, because private keys can be encrypted with a variety of algorithms and key lengths. From https://www.openssl.org/docs/apps/rsa.html: -aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256|-des|-des3|-idea These options encrypt the private key with the specified cipher before outputting it. A pass phrase is prompted for. If none of these options is specified the key is written in plain text. This means that using the rsa utility to read in an encrypted key with no encryption option can be used to remove the pass phrase from a key, or by setting the encryption options it can be use to add or change the pass phrase. These options can only be used with PEM format output files. The computational complexity depends on the cipher. The difficulty of deriving the key depends on three things: the length of the passphrase (the external key), the length of the cipher's key (the internal key, which is generated from the external key), and whether there are any attacks better than brute force. We can disregard the last possibility. There are attacks on DES better than brute force, but they're not feasible. If there are better-than-brute-force attacks on any of the other ciphers, they haven't been published, and it's not worth worrying about them; you can't do anything about it. Regarding the first two, the relevant one will be determined by whether there's more entropy in the passphrase than in the internal cipher key. If your passphrase has, say, 180 bits of entropy, then you'd be discarding some entropy if you use AES-128 or Camellia-128. On the other hand, there's little benefit in that case to choosing AES-256 over AES-192. (There's potentially some benefit in making an attacker with limited knowledge do extra work.) But even if, let's say, you use a cipher with a 128-bit key, and your passphrase contains at least 128 bits of entropy, then an attacker is looking at 2^127 decryptions, on average, to brute-force the key. That's on the order of 10^38. If they can do a trillion (10^9) decryptions a second, they're still looking at around 10^22 years to recover the key. They'll probably get bored before then. Of course, your passphrases don't contain 128 bits of entropy. From your first message, you're talking about a random 10-character passphrase chosen from a 52-character alphabet. That's only about 57 bits, if I haven't made a mistake in my back-of-the-envelope calculations. So 2^56 decryptions on average to brute-force a key. With my theoretical trillion-decryptions-a-second attack, that'd take around two years. But 10^9 decryptions/second isn't a real-world value; I just made it up for the purposes of discussion. Osvik et al [2010]http://www.scs.stanford.edu/~deian/pubs/osvik:2010:fast.pdf reported a peak speed of 30.8 Gb/sec for AES software decryption; that's four years ago, but let's assume it's still fairly close to what any attacker is likely to mount against your system. You haven't said how long your private keys are; let's use the NIST recommendation of 2048 bits. So that gives us 1.6e7 key decryptions per second. So if the state of the art has improved by an order of magnitude since 2010, and if your attacker puts together a cluster of 100 such state-of-the-art machines, they could probably break one of your keys in a couple of months. That doesn't look like a plausible threat to me, unless you're protecting something really valuable. Disclaimer - I haven't double-checked any of those figures. Does that help? Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Friday, 05 September, 2014 16:32 To: Salz, Rich Subject: Re: Certificate pass phrase brute force... There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won't be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz I wasn't as clear in my initial post as I should have been. These are client _keys_ [as Michael Wojcik correctly points out, they're actually keys - sorry.] for OpenVPN to connect to the corporate network. You have to have a client certificate+key [generated by OpenSSL] and the pass-phrase given when the key was created. Pass-phrases are unique for each key. Pass phrases are created by the sys-admin [us], not the end user. I'll try to respond to several of the points in a single post. @dave: We can't limit the number
Re: Why does OpenSSL own all the prefixes in the world?
In message
2a0efb9c05d0164e98f19bb0af3708c71d12a97...@usmbx1.msg.corp.akamai.com on Mon,
8 Sep 2014 08:57:55 -0400, Salz, Rich rs...@akamai.com said:
rsalz My suggestion is indeed that openssl lib switch to C++, at least for
rsalz namespace usage.
rsalz
rsalz That would be nice to have. But C++ classes are like opinions --
everyone has one, nobody wants to use anyone else's. :)
rsalz
rsalz I'd be surprised if OpenSSL started work on this, but I'd encourage
interested folks to work on it.
Nothing really stops us from creating a C++ namespace. After all, we
do have the following construct in quite a number if not all exported
header files:
#ifdef __cplusplus
extern C {
#endif
/* yada yada yada */
#ifdef __cplusplus
}
#endif
What's stopping us from specifying a namespace in there, technically
speaking? I mean, except for backward compatibility (people will
suddenly HAVE to have a line saying using namespace openssl; or
something like that).
Cheers,
Richard
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
Life is a tremendous celebration - and I'm invited!
-- from a friend's blog, translated from Swedish
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
The extern C makes it difficult to put things into a namespace. You'd either have to write class declarations that used NO public openssl header files in their public declaration, or we'd have to change the extern C wrappers to be something like #if defined(__cplusplus) !defined(OPENSSL_NAMESPACED_API) -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Richard Levitte
Sent: Monday, 08 September, 2014 10:13
To: openssl-users@openssl.org
Nothing really stops us from creating a C++ namespace. After all, we
do have the following construct in quite a number if not all exported
header files:
#ifdef __cplusplus
extern C {
#endif
/* yada yada yada */
#ifdef __cplusplus
}
#endif
What's stopping us from specifying a namespace in there, technically
speaking? I mean, except for backward compatibility (people will
suddenly HAVE to have a line saying using namespace openssl; or
something like that).
Since all the OpenSSL declarations are in an extern-C block, identifier names
aren't mangled, so the namespace has no effect on external visibility. And
namespaces don't affect macro names. So there's little benefit - it'd be a
purely lexical change that only affects how OpenSSL functions are named within
C++ translation units. It doesn't help with macro or external-symbol identifier
collisions.
And anyone who wants this can simply include the OpenSSL headers within a
namespace declaration.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
In message CALiegf=+4vr1GU=mn4r0hng99orugtvez+xxjogpbkzx-uz...@mail.gmail.com on Mon, 8 Sep 2014 15:10:04 +0200, Iñaki Baz Castillo i...@aliax.net said: ibc 2014-09-08 14:44 GMT+02:00 Iñaki Baz Castillo i...@aliax.net: ibc -- ibc int read = BIO_read(sslBioToNetwork, (void*)myBuffer, MY_BUFFER_SIZE); ibc ibc // Use the read data ibc -- ibc ibc with something like this: ibc ibc --- ibc long read; ibc char** data = (char**)myBuffer; ibc ibc read = BIO_get_mem_data(sslBioToNetwork, data); ibc ibc // Emtpy the BIO buffer data, HOW? ibc ibc // Use the read data ibc --- ibc ibc ibc But I do not know how to empty the already read BIO buffer data. ibc BIO_flush() does nothing. ibc ibc ibc Sorry, BIO_flush() works. The problem is that calling BIO_eof() after ibc BIO_flush() does not return 1 so I get a loop. Updated my code not to ibc check BIO_eof() after BIO_flush(). Sorry, BIO_flush() isn't what you want (it doesn't reset the buffer to empty), BIO_reset() is. However, you need to be careful... if I were you, I would use the read data before resetting, as BIO_get_mem_data() gives you the pointer to the internal BIO_s_mem buffer, not to a duplicate of it. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
2014-09-08 16:08 GMT+02:00 Richard Levitte rich...@levitte.org: Sorry, BIO_flush() isn't what you want (it doesn't reset the buffer to empty), BIO_reset() is. However, you need to be careful... if I were you, I would use the read data before resetting, as BIO_get_mem_data() gives you the pointer to the internal BIO_s_mem buffer, not to a duplicate of it. Thanks, it does work. However... I do not understand how... This works fine: --- long read; // myBuffer is an already allocated buffer. char** data = (char**)myBuffer; read = BIO_get_mem_data(bio, data); // Use data and read values. BIO_reset(bio); --- This crashes: --- long read; char** data = NULL; read = BIO_get_mem_data(bio, data); // Use data and read values. BIO_reset(bio); --- Why do I need to provide BIO_get_mem_data() with an already allocated buffer? I've checked the function and I do not understand what it does). The only I want is to get the pointer to the BIO's buffer in which SSL_write() wrote. Why should I provide an allocated buffer? The BIO already has a buffer and the data is already in there after calling SSL_write(). Why do I need to pass an allocated buffer? Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
2014-09-08 18:19 GMT+02:00 Iñaki Baz Castillo i...@aliax.net: This works fine: --- long read; // myBuffer is an already allocated buffer. char** data = (char**)myBuffer; read = BIO_get_mem_data(bio, data); // Use data and read values. BIO_reset(bio); --- BTW I've realized that it also works by removing the BIO_reset() call. I assume that SSL_write() writes into the BIO and overrides the existing data (and the BIO buffer length gets updated with the most recent written data). -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
The allocated buffer needs to be sizeof(char *). What's happening is the address of the buffer (buffer[0]) gets written to the pointer-to-pointer-to-char, data. If data == NULL, you're asking to write the address of the buffer to unallocated memory. It's done this way because the return value of the function is the number of valid bytes you can read from that location, and the address must go somewhere for you to get the data from it. I'm sorry this is probably difficult to understand, I don't know if I can explain it more easily. -Kyle H On September 8, 2014 9:19:09 AM PST, Iñaki Baz Castillo i...@aliax.net wrote: 2014-09-08 16:08 GMT+02:00 Richard Levitte rich...@levitte.org: Sorry, BIO_flush() isn't what you want (it doesn't reset the buffer to empty), BIO_reset() is. However, you need to be careful... if I were you, I would use the read data before resetting, as BIO_get_mem_data() gives you the pointer to the internal BIO_s_mem buffer, not to a duplicate of it. Thanks, it does work. However... I do not understand how... This works fine: --- long read; // myBuffer is an already allocated buffer. char** data = (char**)myBuffer; read = BIO_get_mem_data(bio, data); // Use data and read values. BIO_reset(bio); --- This crashes: --- long read; char** data = NULL; read = BIO_get_mem_data(bio, data); // Use data and read values. BIO_reset(bio); --- Why do I need to provide BIO_get_mem_data() with an already allocated buffer? I've checked the function and I do not understand what it does). The only I want is to get the pointer to the BIO's buffer in which SSL_write() wrote. Why should I provide an allocated buffer? The BIO already has a buffer and the data is already in there after calling SSL_write(). Why do I need to pass an allocated buffer? Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: How to empty a BIO buffer?
2014-09-08 18:35 GMT+02:00 Kyle Hamilton aerow...@gmail.com: The allocated buffer needs to be sizeof(char *). What's happening is the address of the buffer (buffer[0]) gets written to the pointer-to-pointer-to-char, data. If data == NULL, you're asking to write the address of the buffer to unallocated memory. It's done this way because the return value of the function is the number of valid bytes you can read from that location, and the address must go somewhere for you to get the data from it. I'm sorry this is probably difficult to understand, I don't know if I can explain it more easily. It's clear. And my error was terrible, I was creating a char** data instead of char* data. The following updated code does work: - long read; char* data = NULL; read = BIO_get_mem_data(bio, data); // Use data and read values. - Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Performance related queries for SSL based client server model
Hi,
I am trying with simple client server model where it is reading datat
from a file and calling SSL_write and similar thing is happening on other
end i.e. reading from SSL using SSL_read and writing to file. Itis taking
40 mins of time to copy file of size 600 MB and if I run a non-ssl client
server (i.e. pure TCP socket application ) it finishes in 5-6 mins and also
on same network scp is taking 10 mins. One thing I observerd by looking
into scp code that it does not use SSL provided APIs (i.e.SSL_Read or
SSL_Write) but they use it differenly i.e. might be directly calling
encryption APIs and writing data to sockets. But I don't have much
understanding what SSL_Write or SSL_read does internally . So wanted to
understand if there is any way to improve performance of SSL_Read or
SSL_write to achive high performance. Following are my client server
programmes. Here client writes file on server machine in hardcoded
location and name.
Client
//SSL-Client.c
#include stdio.h
#include errno.h
#include unistd.h
#include malloc.h
#include string.h
#include sys/socket.h
#include resolv.h
#include netdb.h
#include openssl/ssl.h
#include openssl/err.h
#include sys/stat.h
#include fcntl.h
#include netinet/tcp.h
#include netinet/ip.h
#define FAIL-1
int OpenConnection(const char *hostname, int port)
{ int sd;
struct hostent *host;
struct sockaddr_in addr;
if ( (host = gethostbyname(hostname)) == NULL )
{
perror(hostname);
abort();
}
sd = socket(PF_INET, SOCK_STREAM, 0);
bzero(addr, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(port);
addr.sin_addr.s_addr = *(long*)(host-h_addr);
if ( connect(sd, (struct sockaddr*)addr, sizeof(addr)) != 0 )
{
close(sd);
perror(hostname);
abort();
}
return sd;
}
SSL_CTX* InitCTX(void)
{ SSL_METHOD *method;
SSL_CTX *ctx;
OpenSSL_add_all_algorithms(); /* Load cryptos, et.al. */
SSL_load_error_strings(); /* Bring in and register error messages */
method = SSLv2_client_method(); /* Create new client-method instance */
ctx = SSL_CTX_new(method); /* Create new context */
if ( ctx == NULL )
{
ERR_print_errors_fp(stderr);
abort();
}
return ctx;
}
void ShowCerts(SSL* ssl)
{ X509 *cert;
char *line;
cert = SSL_get_peer_certificate(ssl); /* get the server's certificate */
if ( cert != NULL )
{
printf(Server certificates:\n);
line = X509_NAME_oneline(X509_get_subject_name(cert), 0, 0);
printf(Subject: %s\n, line);
free(line); /* free the malloc'ed string */
line = X509_NAME_oneline(X509_get_issuer_name(cert), 0, 0);
printf(Issuer: %s\n, line);
free(line); /* free the malloc'ed string */
X509_free(cert); /* free the malloc'ed certificate copy */
}
else
printf(No certificates.\n);
}
int main(int count, char *strings[])
{ SSL_CTX *ctx;
int server;
SSL *ssl;
char buf[1024];
int bytes;
char *hostname, *portnum;
char recvBuff[16*1024];
int fd=0;
int mode,i,n,len;
int total=0;
if ( count != 4 )
{
printf(usage: %s hostname portnumFileName\n, strings[0]);
exit(0);
}
SSL_library_init();
hostname=strings[1];
portnum=strings[2];
ctx = InitCTX();
server = OpenConnection(hostname, atoi(portnum));
ssl = SSL_new(ctx); /* create new SSL connection state */
SSL_set_fd(ssl, server);/* attach the socket descriptor */
if ( SSL_connect(ssl) == FAIL ) /* perform the connection */
ERR_print_errors_fp(stderr);
else
{ char *msg = Hello???;
printf(Connected with %s encryption\n, SSL_get_cipher(ssl));
ShowCerts(ssl);/* get any certs */
fd=open(strings[3],O_RDWR);
while ( (n = read(fd, recvBuff, sizeof(recvBuff)-1)) 0)
{
recvBuff[n] = 0;
mode=n;
i=0;
while(mode0)
{
len=SSL_write(ssl, recvBuff,mode ); /* encrypt send
message */
total+=len;
mode=mode-len;
}
}
bytes = SSL_read(ssl, buf, sizeof(buf)); /* get reply decrypt */
buf[bytes] = 0;
printf(Received: \%s\\n, buf);
SSL_free(ssl);/* release connection state */
}
close(server); /* close socket */
SSL_CTX_free(ctx);/* release context */
return 0;
}
Server Programme
-
//SSL-Server.c
#include errno.h
#include unistd.h
#include malloc.h
#include string.h
#include arpa/inet.h
#include sys/socket.h
#include sys/types.h
#include netinet/in.h
#include resolv.h
#include openssl/ssl.h
#include openssl/err.h
#include sys/stat.h
#include fcntl.h
#include netinet/tcp.h
#include netinet/ip.h
#define FAIL-1
Hang during SSL /connect - accept
Were are occasionally seeing hangs when establishing an SSL connection with OpenSSL 1.0.1i. This connection uses SRP and both the server and the client sockets are in blocking mode (thus the hang). Is there anything I can do to debug this problem? Client side: gdb) where #0 0x7f91e412dd2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f91b3749423 in sock_read (b=0x2585720, out=0x2580093 \025\003\002, outl=5) at bss_sock.c:142 #2 0x7f91b3716c5c in BIO_read (b=0x2585720, out=0x2580093, outl=5) at bio_lib.c:212 #3 0x7f91b380cc77 in ssl3_read_n (s=0x260bed0, n=5, max=5, extend=0) at s3_pkt.c:240 #4 0x7f91b380cec3 in ssl3_get_record (s=0x260bed0) at s3_pkt.c:317 #5 0x7f91b380e43d in ssl3_read_bytes (s=0x260bed0, type=22, buf=0x2614360 \024, len=4, peek=0) at s3_pkt.c:1024 #6 0x7f91b37fde3d in ssl3_get_message (s=0x260bed0, st1=4576, stn=4577, mt=-1, max=16384, ok=0x7fff4461ed00) at s3_both.c:457 #7 0x7f91b3804979 in ssl3_get_new_session_ticket (s=0x260bed0) at s3_clnt.c:2060 #8 0x7f91b3800e12 in ssl3_connect (s=0x260bed0) at s3_clnt.c:545 #9 0x7f91b383407e in SSL_connect (s=0x260bed0) at ssl_lib.c:949 #10 0x7f91b240230d in GsSslState::SSL_connect (this=0x7f91b2e6b740 SslState, ssl=0x260bed0) at /export/ghana1/users/bretlb/trunk/src/sslsocket.c:518 Server Side (gdb) where #0 0x7f669ae5ad2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f666a475423 in sock_read (b=0x1082990, out=0x1088473 \026\003\002, outl=5) at bss_sock.c:142 #2 0x7f666a442c5c in BIO_read (b=0x1082990, out=0x1088473, outl=5) at bio_lib.c:212 #3 0x7f666a538c77 in ssl3_read_n (s=0x1082180, n=5, max=5, extend=0) at s3_pkt.c:240 #4 0x7f666a538ec3 in ssl3_get_record (s=0x1082180) at s3_pkt.c:317 #5 0x7f666a53a43d in ssl3_read_bytes (s=0x1082180, type=22, buf=0x1082f2c \243Lk\327u\f\352\372\037\301\315\353\325\322\377\304\034\343\275ɖb-\030\f\314\371l\320Z\237\315!\223\336\v\266\355\027\271\063c\033\331R\255C\237, incomplete sequence \330..., len=12735, peek=0) at s3_pkt.c:1024 #6 0x7f666a52a18d in ssl3_get_message (s=0x1082180, st1=8608, stn=8609, mt=-1, max=16384, ok=0x7fff4d35eb50) at s3_both.c:538 #7 0x7f666a5416ae in ssl3_get_cert_verify (s=0x1082180) at s3_srvr.c:2926 #8 0x7f666a53c7e9 in ssl3_accept (s=0x1082180) at s3_srvr.c:680 #9 0x7f666a560042 in SSL_accept (s=0x1082180) at ssl_lib.c:940 #10 0x7f669731b0fb in GsSslState::SSL_accept (this=0x7f669800fd20 SslState, ssl=0x1082180) at /export/ghana1/users/bretlb/trunk/src/sslsocket.c:528 Thanks in advance for any help given, Norm Green __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate pass phrase brute force...
Continuing top posting. [Which doesn't bother me nearly as much as it seems to
bother others... ]
Yes! That was a fantastic answer.
...
[A while later]
So, I need to run this down, but it looks like the easy-rsa script uses 3DES to
do encryption - which seems incredibly foolish when we have aes-256 available.
[Though I suppose 3DES is less computationally expensive for weak processors -
but still a bad trade-off, IMO Actually more reading seems to indicate that
perhaps 3DES is harder for general purpose CPU, but with a smaller key-space.
I'd guess a DES vs. AES specific processor would make DES far more vulnerable
{pulling that guess from, well, you know where... :) }. ]
I think it's safe to assume that 3DES is almost certainly a lousier choice than
AES or Camellia on multiple fronts.
I've posed a question to the OpenVPN folks, about the EasyRSA script, and it
appears easy enough to change the encryption type in the script itself, which
I'll do if they don't.
Well, that was a fruitful question and personal research task. At least I
*know* more about the situation than I did before. It may, or may not, change
the entropy of my passwords, or make me do a lot different in the future - but
even if it doesn't - I'm a lot more knowledgeable about what's going on and can
make informed decisions about how to handle things from here on.
So, thanks to all for your input.
BTW, I especially like:
If they can do a trillion (10^9) decryptions a second, they're still looking at
around 10^22 years to recover the key. *They'll probably get bored before then.*
Sort of like the 3DES vs AES discussion here:
http://security.stackexchange.com/questions/26179/security-comparsion-of-3des-and-aes
...and quote ...
AES uses 128-bit blocks, for a limit of 2^128/2 blocks, i.e. 2^68 bytes, also
known as quite a lot of data
Thanks again!
-Greg
OK, that clarifies the situation and your question.
It's impossible to provide a specific answer, because private keys can be
encrypted with a variety of algorithms and key lengths. From
https://www.openssl.org/docs/apps/rsa.html:
-aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256|-des|-des3|-idea
These options encrypt the private key with the specified cipher before
outputting it. A pass phrase is prompted for. If none of these options is
specified the key is written in plain text. This means that using the rsa
utility to read in an encrypted key with no encryption option can be used to
remove the pass phrase from a key, or by setting the encryption options it can
be use to add or change the pass phrase. These options can only be used with
PEM format output files.
The computational complexity depends on the cipher. The difficulty of deriving
the key depends on three things: the length of the passphrase (the external
key), the length of the cipher's key (the internal key, which is generated from
the external key), and whether there are any attacks better than brute force.
We can disregard the last possibility. There are attacks on DES better than
brute force, but they're not feasible. If there are better-than-brute-force
attacks on any of the other ciphers, they haven't been published, and it's not
worth worrying about them; you can't do anything about it.
Regarding the first two, the relevant one will be determined by whether there's
more entropy in the passphrase than in the internal cipher key. If your
passphrase has, say, 180 bits of entropy, then you'd be discarding some entropy
if you use AES-128 or Camellia-128. On the other hand, there's little benefit
in that case to choosing AES-256 over AES-192. (There's potentially some
benefit in making an attacker with limited knowledge do extra work.)
But even if, let's say, you use a cipher with a 128-bit key, and your
passphrase contains at least 128 bits of entropy, then an attacker is looking
at 2^127 decryptions, on average, to brute-force the key. That's on the order
of 10^38. If they can do a trillion (10^9) decryptions a second, they're still
looking at around 10^22 years to recover the key. They'll probably get bored
before then.
Of course, your passphrases don't contain 128 bits of entropy. From your first
message, you're talking about a random 10-character passphrase chosen from a
52-character alphabet. That's only about 57 bits, if I haven't made a mistake
in my back-of-the-envelope calculations. So 2^56 decryptions on average to
brute-force a key. With my theoretical trillion-decryptions-a-second attack,
that'd take around two years.
But 10^9 decryptions/second isn't a real-world value; I just made it up for the
purposes of discussion. Osvik et al [2010] reported a peak speed of 30.8 Gb/sec
for AES software decryption; that's four years ago, but let's assume it's still
fairly close to what any attacker is likely to mount against your system. You
haven't said how long your private keys are; let's use the NIST recommendation
of
Re: Certificate pass phrase brute force...
I think it's safe to assume that 3DES is almost certainly a lousier choice
than AES or Camellia on multiple fronts.
Two key triple DES provides about 80-bits of security, and three key triple
DES provides 112-bits of security. Do you know which they are using?
AES-128 provides about 128-bits of security; and AES-256 provides about
256-bits of security.
If it was a new system, you probably would chose AES or Camellia. If they
are using three key triple DES with 112-bits of security, then there
shouldn't be any loud objections.
At those security levels, the adversary is not going to attack the block
cipher. They are going to attack the password or some other [weak] part in
the system.
Jeff
On Mon, Sep 8, 2014 at 4:00 PM, Gregory Sloop gr...@sloop.net wrote:
Continuing top posting. [Which doesn't bother me nearly as much as it
seems to bother others... ]
Yes! That was a fantastic answer.
...
[A while later]
So, I need to run this down, but it looks like the easy-rsa script uses
3DES to do encryption - which seems incredibly foolish when we have aes-256
available.
[Though I suppose 3DES is less computationally expensive for weak
processors - but still a bad trade-off, IMO Actually more reading seems
to indicate that perhaps 3DES is harder for general purpose CPU, but with a
smaller key-space. I'd guess a DES vs. AES specific processor would make
DES far more vulnerable {pulling that guess from, well, you know where...
:) }. ]
I think it's safe to assume that 3DES is almost certainly a lousier choice
than AES or Camellia on multiple fronts.
I've posed a question to the OpenVPN folks, about the EasyRSA script, and
it appears easy enough to change the encryption type in the script itself,
which I'll do if they don't.
Well, that was a fruitful question and personal research task. At least I
*know* more about the situation than I did before. It may, or may not,
change the entropy of my passwords, or make me do a lot different in the
future - but even if it doesn't - I'm a lot more knowledgeable about what's
going on and can make informed decisions about how to handle things from
here on.
So, thanks to all for your input.
BTW, I especially like:
If they can do a trillion (10^9) decryptions a second, they're still
looking at around 10^22 years to recover the key. *They'll probably get
bored before then.*
Sort of like the 3DES vs AES discussion here:
http://security.stackexchange.com/questions/26179/security-comparsion-of-3des-and-aes
...and quote ...
AES uses 128-bit blocks, for a limit of 2^128/2 blocks, i.e. 2^68 bytes,
also known as quite a lot of data
Thanks again!
...
Re: Hang during SSL /connect - accept
On Mon, Sep 08, 2014 at 11:45:59AM -0700, Norm Green wrote: Were are occasionally seeing hangs when establishing an SSL connection with OpenSSL 1.0.1i. This connection uses SRP and both the server and the client sockets are in blocking mode (thus the hang). Is there anything I can do to debug this problem? A recording (PCAP network capture) of the handshake in question up to the point at which the server and client deadlock, each waiting for the other to say something, would be useful. Client side: gdb) where #0 0x7f91e412dd2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f91b3749423 in sock_read (b=0x2585720, out=0x2580093 \025\003\002, outl=5) at bss_sock.c:142 #2 0x7f91b3716c5c in BIO_read (b=0x2585720, out=0x2580093, outl=5) at bio_lib.c:212 #3 0x7f91b380cc77 in ssl3_read_n (s=0x260bed0, n=5, max=5, extend=0) at s3_pkt.c:240 #4 0x7f91b380cec3 in ssl3_get_record (s=0x260bed0) at s3_pkt.c:317 #5 0x7f91b380e43d in ssl3_read_bytes (s=0x260bed0, type=22, buf=0x2614360 \024, len=4, peek=0) at s3_pkt.c:1024 #6 0x7f91b37fde3d in ssl3_get_message (s=0x260bed0, st1=4576, stn=4577, mt=-1, max=16384, ok=0x7fff4461ed00) at s3_both.c:457 #7 0x7f91b3804979 in ssl3_get_new_session_ticket (s=0x260bed0) at s3_clnt.c:2060 #8 0x7f91b3800e12 in ssl3_connect (s=0x260bed0) at s3_clnt.c:545 Printing the SSL state could also be useful here in frame #8: print *s #9 0x7f91b383407e in SSL_connect (s=0x260bed0) at ssl_lib.c:949 #10 0x7f91b240230d in GsSslState::SSL_connect (this=0x7f91b2e6b740 SslState, ssl=0x260bed0) at /export/ghana1/users/bretlb/trunk/src/sslsocket.c:518 Server Side (gdb) where #0 0x7f669ae5ad2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f666a475423 in sock_read (b=0x1082990, out=0x1088473 \026\003\002, outl=5) at bss_sock.c:142 #2 0x7f666a442c5c in BIO_read (b=0x1082990, out=0x1088473, outl=5) at bio_lib.c:212 #3 0x7f666a538c77 in ssl3_read_n (s=0x1082180, n=5, max=5, extend=0) at s3_pkt.c:240 #4 0x7f666a538ec3 in ssl3_get_record (s=0x1082180) at s3_pkt.c:317 #5 0x7f666a53a43d in ssl3_read_bytes (s=0x1082180, type=22, buf=0x1082f2c \243Lk\327u\f\352\372\037\301\315\353\325\322\377\304\034\343\275?b-\030\f\314\371l\320Z\237\315!\223\336\v\266\355\027\271\063c\033\331R\255C\237, incomplete sequence \330..., len=12735, peek=0) at s3_pkt.c:1024 #6 0x7f666a52a18d in ssl3_get_message (s=0x1082180, st1=8608, stn=8609, mt=-1, max=16384, ok=0x7fff4d35eb50) at s3_both.c:538 #7 0x7f666a5416ae in ssl3_get_cert_verify (s=0x1082180) at s3_srvr.c:2926 Also print the server SSL structure. The server seems to be expecting a client certificate perhaps? I would not expect a client certificate with SRP. What is the agreed cipher suite? A PCAP with all previous messages would be most useful. #8 0x7f666a53c7e9 in ssl3_accept (s=0x1082180) at s3_srvr.c:680 #9 0x7f666a560042 in SSL_accept (s=0x1082180) at ssl_lib.c:940 #10 0x7f669731b0fb in GsSslState::SSL_accept (this=0x7f669800fd20 SslState, ssl=0x1082180) at /export/ghana1/users/bretlb/trunk/src/sslsocket.c:528 -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Performance related queries for SSL based client server model
On Mon, Sep 08, 2014 at 11:16:46PM +0530, Alok Sharma wrote:
while ( (n = read(fd, recvBuff, sizeof(recvBuff)-1)) 0)
{
recvBuff[n] = 0;
mode=n;
i=0;
while(mode0)
{
len=SSL_write(ssl, recvBuff, mode);
total+=len;
mode=mode-len;
}
}
The inner loop is wrong unless all the data is always written on
each SSL_write() call.
bytes = SSL_read(ssl, buf, sizeof(buf)); /* get reply decrypt */
buf[bytes] = 0;
printf(Received: \%s\\n, buf);
SSL_free(ssl);/* release connection state */
Why do you expect data back from the server? It is surely still
waiting for more data from the client, since there is no explicit
message framing to indicate to the server that all the data is
sent, and it should reply. You're freeing the SSL state without
a gracefull SSL_shutdown() (often called twice, see the docs).
while(1)
{
bytes = SSL_read(ssl, buf, sizeof(buf)); /* get request */
if ( bytes 0 )
{
// printf(Client msg: \%s\\n, buf);
//sprintf(reply, HTMLecho, buf); /* construct reply */
//SSL_write(ssl, reply, strlen(reply)); /* send reply */
len=bytes;
mode=len;
while(mode0)
{
len1=write(fd,buf,len);
mode=mode-len1;
len-=len1;
}
}
else {
ERR_print_errors_fp(stderr);
break;
}
}
THe inner loop is wrong unless all the data is written on each
write(2) call. The server is in an infinite read loop, deadlocked
with the client.
}
sd = SSL_get_fd(ssl); /* get socket connection */
SSL_free(ssl); /* release SSL state */
close(sd); /* close connection */
And sends no reply. This code is broken, and should block forever
with SSL_read()/SSL_write() replaced with read()/write(). Since
you're reporting finite completion times, you're not posting the
code you're testing, which wastes everyone's time.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Hang during SSL /connect - accept
Thanks Victor. I don't have a handshake recording for these stacks.
The problem occurs intermittently. I've dumped the SSL state and method
objects for the server and client. Anything else you want to see while
the processes are still alive?
Norm
Here's the SSL state and method from the server:
(gdb) p *s
$1 = {version = 770, type = 8192, method = 0x7f666a831040
TLSv1_1_server_method_data.15190, rbio = 0x1082990, wbio = 0x1090e80,
bbio = 0x1090e80, rwstate = 3, in_handshake = 1,
handshake_func = 0x7f666a53b962 ssl3_accept, server = 1,
new_session = 0, quiet_shutdown = 0, shutdown = 0, state = 8609, rstate
= 240, init_buf = 0x1082ef0, init_msg = 0x1082f14, init_num = 24,
init_off = 0, packet = 0x1088473 \026\003\002, packet_length = 0,
s2 = 0x0, s3 = 0x10824b0, d1 = 0x0, read_ahead = 0, msg_callback = 0x0,
msg_callback_arg = 0x0, hit = 0, param = 0x1081f30,
cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0,
enc_read_ctx = 0x1093830, read_hash = 0x1093980, expand = 0x0,
enc_write_ctx = 0x0, write_hash = 0x0, compress = 0x0, cert = 0x1081e00,
sid_ctx_length = 0, sid_ctx = '\000' repeats 31 times, session =
0x1093020, generate_session_id = 0x0, verify_mode = 0, verify_callback =
0x0, info_callback = 0x0, error = 0, error_code = 0,
psk_client_callback = 0x0, psk_server_callback = 0x0, ctx =
0x10813e0, debug = 0, verify_result = 0, ex_data = {sk = 0x0, dummy =
0}, client_CA = 0x0, references = 1, options = 4, mode = 4,
max_cert_list = 102400, first_packet = 0, client_version = 770,
max_send_fragment = 16384, tlsext_debug_cb = 0x0, tlsext_debug_arg =
0x0, tlsext_hostname = 0x0, servername_done = 0, tlsext_status_type = -1,
tlsext_status_expected = 0, tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts =
0x0, tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1,
tlsext_ticket_expected = 1, tlsext_ecpointformatlist_length = 0,
tlsext_ecpointformatlist = 0x0, tlsext_ellipticcurvelist_length = 0,
tlsext_ellipticcurvelist = 0x0, tlsext_opaque_prf_input = 0x0,
tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0,
tls_session_ticket_ext_cb = 0x0, tls_session_ticket_ext_cb_arg = 0x0,
tls_session_secret_cb = 0x0, tls_session_secret_cb_arg = 0x0,
initial_ctx = 0x10813e0, next_proto_negotiated = 0x0,
next_proto_negotiated_len = 0 '\000', srtp_profiles = 0x0,
srtp_profile = 0x0, tlsext_heartbeat = 1, tlsext_hb_pending = 0,
tlsext_hb_seq = 0, renegotiate = 2, srp_ctx = {
SRP_cb_arg = 0x7f669800bd00 srpInfo,
TLS_ext_srp_username_callback = 0x7f6697319112 srp_server_cb(SSL*,
int*, void*), SRP_verify_param_callback = 0x0,
SRP_give_srp_client_pwd_callback = 0x0,
login = 0x10932d0 qauser3, N = 0x1082eb0, g = 0x1093520, s =
0x1093560, B = 0x10937b0, A = 0x1093a40, a = 0x0, b = 0x10936c0, v =
0x10935a0, info = 0x0, strength = 1024, srp_Mask = 1024}}
(gdb)
(gdb) p s-method
$1 = (const SSL_METHOD *) 0x7f666a831040 TLSv1_1_server_method_data.15190
(gdb) p *s-method
$2 = {version = 770, ssl_new = 0x7f666a56e8ff tls1_new, ssl_clear =
0x7f666a56e97b tls1_clear, ssl_free = 0x7f666a56e93e tls1_free,
ssl_accept = 0x7f666a53b962 ssl3_accept,
ssl_connect = 0x7f666a5634c1 ssl_undefined_function, ssl_read =
0x7f666a538735 ssl3_read, ssl_peek = 0x7f666a538762 ssl3_peek,
ssl_write = 0x7f666a5384a4 ssl3_write,
ssl_shutdown = 0x7f666a53835b ssl3_shutdown, ssl_renegotiate =
0x7f666a53878f ssl3_renegotiate, ssl_renegotiate_check =
0x7f666a5387e3 ssl3_renegotiate_check,
ssl_get_message = 0x7f666a529cfb ssl3_get_message, ssl_read_bytes =
0x7f666a53a184 ssl3_read_bytes, ssl_write_bytes = 0x7f666a539754
ssl3_write_bytes,
ssl_dispatch_alert = 0x7f666a53b6f3 ssl3_dispatch_alert, ssl_ctrl =
0x7f666a536564 ssl3_ctrl, ssl_ctx_ctrl = 0x7f666a536e55
ssl3_ctx_ctrl, get_cipher_by_char = 0x7f666a5376cf
ssl3_get_cipher_by_char,
put_cipher_by_char = 0x7f666a53774c ssl3_put_cipher_by_char,
ssl_pending = 0x7f666a535e3b ssl3_pending, num_ciphers =
0x7f666a535dff ssl3_num_ciphers, get_cipher = 0x7f666a535e0a
ssl3_get_cipher,
get_ssl_method = 0x7f666a574040 tls1_get_server_method, get_timeout
= 0x7f666a56e8f4 tls1_default_timeout, ssl3_enc = 0x7f666a847f20
TLSv1_enc_data,
ssl_version = 0x7f666a5634f5 ssl_undefined_void_function,
ssl_callback_ctrl = 0x7f666a536d79 ssl3_callback_ctrl,
ssl_ctx_callback_ctrl = 0x7f666a53757b ssl3_ctx_callback_ctrl}
(gdb)
And from the client:
$1 = {version = 770, type = 4096, method = 0x7f91b3b04a40
TLSv1_1_client_method_data.15190, rbio = 0x2585720, wbio = 0x260c210,
bbio = 0x260c210, rwstate = 3, in_handshake = 1,
handshake_func = 0x7f91b38002df ssl3_connect, server = 0,
new_session = 0, quiet_shutdown = 0, shutdown = 2, state = 4576, rstate
= 240, init_buf = 0x260c290, init_msg = 0x2614364, init_num = 0,
init_off = 0, packet = 0x2580093 \025\003\002, packet_length = 0,
s2 = 0x0, s3 = 0x253d720, d1 = 0x0, read_ahead = 0, msg_callback = 0x0,
msg_callback_arg = 0x0, hit = 0, param = 0x260c3c0,
cipher_list = 0x0,
On 2K keys and SHA-256
We are considering changing the default keysize (RSA, DSA, DH) from 1K to 2K, and changing the default signing digest from SHA-1 to SHA-256. We've already committed this to HEAD/master. We would like to make this change in the upcoming 1.0.2 release as well. Several downstream distributions, such as Debian, have already done this. Microsoft has already announced deprecation of SHA-1 certificates, and Google just recently posted a fairly aggressive plan for Chrome. Does anyone have strong objections? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
Re: Hang during SSL /connect - accept
On Mon, Sep 08, 2014 at 02:36:20PM -0700, Norm Green wrote:
Thanks Victor. I don't have a handshake recording for these stacks. The
problem occurs intermittently.
Any chance you can capture enough sessions to also nab one (full-size
packet capture) that ran into the problem?
I've dumped the SSL state and method objects
for the server and client. Anything else you want to see while the
processes are still alive?
Here's the SSL state and method from the server:
(gdb) p *s
$1 = {version = 770, type = 8192, method = 0x7f666a831040
TLSv1_1_server_method_data.15190, rbio = 0x1082990, wbio = 0x1090e80, bbio
= 0x1090e80, rwstate = 3, in_handshake = 1,
handshake_func = 0x7f666a53b962 ssl3_accept, server = 1, new_session =
0, quiet_shutdown = 0, shutdown = 0, state = 8609, rstate = 240, init_buf =
0x1082ef0, init_msg = 0x1082f14, init_num = 24,
init_off = 0, packet = 0x1088473 \026\003\002, packet_length = 0, s2 =
0x0, s3 = 0x10824b0, d1 = 0x0, read_ahead = 0, msg_callback = 0x0,
msg_callback_arg = 0x0, hit = 0, param = 0x1081f30,
cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx =
0x1093830, read_hash = 0x1093980, expand = 0x0, enc_write_ctx = 0x0,
write_hash = 0x0, compress = 0x0, cert = 0x1081e00,
sid_ctx_length = 0, sid_ctx = '\000' repeats 31 times, session =
0x1093020,
Much of the interesting state is in the session, so also:
p s-session[0]
And from the client:
$1 = {version = 770, type = 4096, method = 0x7f91b3b04a40
TLSv1_1_client_method_data.15190, rbio = 0x2585720, wbio = 0x260c210, bbio
= 0x260c210, rwstate = 3, in_handshake = 1,
handshake_func = 0x7f91b38002df ssl3_connect, server = 0, new_session =
0, quiet_shutdown = 0, shutdown = 2, state = 4576, rstate = 240, init_buf =
0x260c290, init_msg = 0x2614364, init_num = 0,
init_off = 0, packet = 0x2580093 \025\003\002, packet_length = 0, s2 =
0x0, s3 = 0x253d720, d1 = 0x0, read_ahead = 0, msg_callback = 0x0,
msg_callback_arg = 0x0, hit = 0, param = 0x260c3c0,
cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx =
0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx = 0x253e590, write_hash =
0x2612420, compress = 0x0, cert = 0x25855e0,
sid_ctx_length = 0, sid_ctx = '\000' repeats 31 times, session =
0x2619900,
Ditto here: p s-session[0]
generate_session_id = 0x0, verify_mode = 0, verify_callback =
0x0, info_callback = 0x0, error = 0, error_code = 0,
psk_client_callback = 0x0, psk_server_callback = 0x0, ctx = 0x26127a0,
debug = 0, verify_result = 0, ex_data = {sk = 0x0, dummy = 0}, client_CA =
0x0, references = 1, options = 4, mode = 4,
max_cert_list = 102400, first_packet = 0, client_version = 770,
max_send_fragment = 16384, tlsext_debug_cb = 0x0, tlsext_debug_arg = 0x0,
tlsext_hostname = 0x0, servername_done = 0, tlsext_status_type = -1,
tlsext_status_expected = 0, tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts = 0x0,
tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1, tlsext_ticket_expected =
1, tlsext_ecpointformatlist_length = 0,
tlsext_ecpointformatlist = 0x0, tlsext_ellipticcurvelist_length = 0,
tlsext_ellipticcurvelist = 0x0, tlsext_opaque_prf_input = 0x0,
tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0,
tls_session_ticket_ext_cb = 0x0, tls_session_ticket_ext_cb_arg = 0x0,
tls_session_secret_cb = 0x0, tls_session_secret_cb_arg = 0x0, initial_ctx =
0x26127a0, next_proto_negotiated = 0x0,
next_proto_negotiated_len = 0 '\000', srtp_profiles = 0x0, srtp_profile =
0x0, tlsext_heartbeat = 1, tlsext_hb_pending = 0, tlsext_hb_seq = 0,
renegotiate = 0, srp_ctx = {SRP_cb_arg = 0x0,
TLS_ext_srp_username_callback = 0x0, SRP_verify_param_callback = 0x0,
SRP_give_srp_client_pwd_callback = 0x7f91b380a53f
srp_password_from_info_cb, login = 0x2509ef0 qauser3, N = 0x26198d0,
g = 0x257f4e0, s = 0x257f510, B = 0x257f570, A = 0x257f6b0, a =
0x257f630, b = 0x0, v = 0x0, info = 0x253d188 junkfish, strength = 1024,
srp_Mask = 1024}}
If the string junkfish is sensitive, you may want to change
passwords...
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 16:29 GMT+02:00 Salz, Rich rs...@akamai.com:
The extern C makes it difficult to put things into a namespace. You'd
either have to write class declarations that used NO public openssl header
files in their public declaration, or we'd have to change the extern C
wrappers to be something like
#if defined(__cplusplus) !defined(OPENSSL_NAMESPACED_API)
I've tried the namespace openssl { #include openssl/.h }
approach and it has been terrible. I've ended with compiler error
messages like:
openssl::malloc not found
It makes sense given that the namespace is also affecting to any other
include within the openssl header file.
--
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Performance related queries for SSL based client server model
2014-09-08 19:46 GMT+02:00 Alok Sharma alokonm...@gmail.com: One thing I observerd by looking into scp code that it does not use SSL provided APIs (i.e.SSL_Read or SSL_Write) but they use it differenly i.e. might be directly calling encryption APIs and writing data to sockets. But I don't have much understanding what SSL_Write or SSL_read does internally. It has been already replied above. SSH is not SSL so don't look for SSL_ methods on openssh. Said that, AFAIK openssh uses the crypto library from openssl, but that is not SSL/TLS at all. So wanted to understand if there is any way to improve performance of SSL_Read or SSL_write to achive high performance. Following are my client server programmes. Here client writes file on server machine in hardcoded location and name. You have lot of errors in your program. I suggest that you first properly learn openssl, then measure your code if you need. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Value of DEFAULT cipher suite
We are considering removing weak cryptography from the value of DEFAULT. That is, append :!LOW:!EXPORT It is currently defined as this in include/openssl/ssl.h: #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 Please let us know if you have strong objections to this. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
No objection at all. Perhaps it might be worth checking that the other defaults are sane too at the same time though. e.g. x509 versions etc. Rich. On 8 September 2014 22:59, Salz, Rich rs...@akamai.com wrote: We are considering changing the default keysize (RSA, DSA, DH) from 1K to 2K, and changing the default signing digest from SHA-1 to SHA-256. We've already committed this to HEAD/master. We would like to make this change in the upcoming 1.0.2 release as well. Several downstream distributions, such as Debian, have already done this. Microsoft has already announced deprecation of SHA-1 certificates, and Google just recently posted a fairly aggressive plan for Chrome. Does anyone have strong objections? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz
Updating roadmap objectives: RT backlog
We've updated the roadmap, https://www.openssl.org/about/roadmap.html with information about our progress on the RT backlog: Update (8th September 2014): we have made a great deal of progress on the backlog. A graph of ticket activity[1] is available, as is the raw data[2] for every bug showing when it was open, and resolved. We will update these files periodically. [1] https://www.openssl.org/about/ticket-activity.png [2] https://www.openssl.org/about/buglist.txt Thanks for your interest and support. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: cannot read PEM key file - no start line
Hi Viktor, Thank you so much for your response. Do I need to request for a specific certificate that will is base64? Thanks, Liz -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, September 08, 2014 5:42 AM To: openssl-users@openssl.org Subject: Re: cannot read PEM key file - no start line On Sun, Sep 07, 2014 at 07:26:05PM -0700, Liz Fall wrote: I have checked and verified that there is no whitespace. Also, the BEGIN and END statements look correct. However, each line in the cert is 76 chars in length, except for the last line. Should the lines be 64-characters long? Yes. The OpenSSL base64 decoder limits input lines to 64 characters. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: cannot read PEM key file - no start line
On Mon, Sep 08, 2014 at 05:03:58PM -0700, Liz Fall wrote:
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?
No, you can just re-wrap the base64 data you have to 64 characters
per line. There are two different 64's here. The size of the
base64 encoding alphabet (64 possible choices for each letter) and
the length of the PEM encoded line (64 such letters per line).
The file you have is already base64 encoded, but the line length
is not PEM compatible (PEM requires 64 characters per line). So
just rewrap the lines to use 64 chars on all but the last line.
Example: Same (random) base64 data wrapped to 76 characters per
line and 64 per line:
$ rand=$(mktemp /tmp/rand.XX)
$ openssl rand 1024 $rand
$ echo; echo 76 per line:
$ $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 57)) 0) {
print encode_base64($buf);
}
'
$ echo; echo 64 per line:
$ $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 48)) 0) {
print encode_base64($buf);
}
'
$ rm -f $rand
76 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+TqSTcUHe9
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQzV6AQLY74Hnjs1sZuuUtL6ju
rWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A16R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZq
LwjOR9M2BPiFPeun22GnlibTK+jzIjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38j
cxH5hLcuvtwev+cpuLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtO
kdFZl1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2HQk9ouuKf
wo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM6LhOCD9zGOFxvxC+xYsj
+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWIEMW05cnijpWKdrnrvvFirEeQMnLIJemZ
EPxc57WTh9O/vuZDLGm90qa8FwfUkyLGf7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeo
uykVr8gM5uPldKUMA0zdsUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUk
cStshPOGvMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiCTQYa
E+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqcGABBNzUPaDv1kWgP
wcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/MqnaTjJNuoDsm874si3A3Pb7IbBRyz
021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2
jR/WjhlrOei+of89TIaCaSw22vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5En
f5Ccb5rC2E1IQHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciqBscqeNR9WU7C
EwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7UNlKBmrRal3rAIKDIVJIAQ==
64 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlY
fh+TqSTcUHe96FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQ
zV6AQLY74Hnjs1sZuuUtL6jurWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A1
6R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZqLwjOR9M2BPiFPeun22GnlibTK+jz
IjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38jcxH5hLcuvtwev+cp
uLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtOkdFZ
l1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2H
Qk9ouuKfwo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM
6LhOCD9zGOFxvxC+xYsj+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWI
EMW05cnijpWKdrnrvvFirEeQMnLIJemZEPxc57WTh9O/vuZDLGm90qa8FwfUkyLG
f7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeouykVr8gM5uPldKUMA0zd
sUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUkcStshPOG
vMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiC
TQYaE+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqc
GABBNzUPaDv1kWgPwcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/Mq
naTjJNuoDsm874si3A3Pb7IbBRyz021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5
OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2jR/WjhlrOei+of89TIaCaSw2
2vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5Enf5Ccb5rC2E1I
QHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciq
BscqeNR9WU7CEwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7
UNlKBmrRal3rAIKDIVJIAQ==
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Hang during SSL /connect - accept
On Mon, Sep 08, 2014 at 03:10:47PM -0700, Norm Green wrote: I will try to capture traffic in the next run. Looking at the commit history after 1.0.1i, I think you want: commit 30fbe92c78981a417718bcbf25d295d16c5b7ed9 Author: Dr. Stephen Henson st...@openssl.org Date: Fri Aug 8 11:24:25 2014 +0100 Fix SRP authentication ciphersuites. The addition of SRP authentication needs to be checked in various places to work properly. Specifically: A certificate is not sent. A certificate request must not be sent. Server key exchange message must not contain a signature. If appropriate SRP authentication ciphersuites should be chosen. Reviewed-by: Matt Caswell m...@openssl.org (cherry picked from commit 8f5a8805b82d1ae81168b11b7f1506db9e047dec) -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hang during SSL /connect - accept
Thanks Viktor. I did get some fixes (via this list) from Steve a while back because SRP authenication was completely broken out of the box with 1.0.1i.However I don't know if all the changes in the commit you mentioned have been merged. I will investigate further. Norm On 9/8/14 17:30, Viktor Dukhovni wrote: On Mon, Sep 08, 2014 at 03:10:47PM -0700, Norm Green wrote: I will try to capture traffic in the next run. Looking at the commit history after 1.0.1i, I think you want: commit 30fbe92c78981a417718bcbf25d295d16c5b7ed9 Author: Dr. Stephen Henson st...@openssl.org Date: Fri Aug 8 11:24:25 2014 +0100 Fix SRP authentication ciphersuites. The addition of SRP authentication needs to be checked in various places to work properly. Specifically: A certificate is not sent. A certificate request must not be sent. Server key exchange message must not contain a signature. If appropriate SRP authentication ciphersuites should be chosen. Reviewed-by: Matt Caswell m...@openssl.org (cherry picked from commit 8f5a8805b82d1ae81168b11b7f1506db9e047dec) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate pass phrase brute force...
Well, as I said, given my reading of the code, the newest version of EasyRSA
[line 861] shows the following:
local crypto=-des3
It's in the set_pass function. [On further review of the code, this appears to
only be used by the set-rsa-pass or set-ec-pass functions, and I can't
determine what it uses to encrypt *new* CA/Server/Client keys instead of just
re-encrypting them.]
I'm certainly no bash guru, but it appears to only allow a 3DES encryption for
private keys
Again, all the thoughts about a tall fence, with a weak gate [i.e. attack the
end-device, instead of attacking the key by brute-forcing it, etc] all apply.
But even given those conditions, I think it's foolish choosing a weak
encryption for private keys when you don't absolutely need to do so. And
picking this in a public-use tool seems like a bad choice when many people
will use the tool [EasyRSA] believing that it's done using best practices.
All that said, I'm not entirely sure what it does use from reviewing the code.
[And I haven't had a reply to my query of the OpenVPN/EasyRSA folks, so I might
be entirely wrong.]
--On that note: Is there a way to determine from an encrypted key-file what
encryption was used to encrypt it? [I have the password, so it doesn't need to
be a blind test.]
If someone can give me that information, I can see what the EasyRSA code
actually produces. I can't find a way using OpenSSL - it will decrypt the key,
but doesn't tell me what it used to do so, or tell me about the encryption
method on the key. [But most of what the OpenSSL binaries do is far beyond my
very weak openssl-sauce, so that result isn't surprising.]
-Greg
I think it's safe to assume that 3DES is almost certainly a lousier choice than
AES or Camellia on multiple fronts.
Two key triple DES provides about 80-bits of security, and three key triple DES
provides 112-bits of security. Do you know which they are using? AES-128
provides about 128-bits of security; and AES-256 provides about 256-bits of
security.
If it was a new system, you probably would chose AES or Camellia. If they are
using three key triple DES with 112-bits of security, then there shouldn't be
any loud objections.
At those security levels, the adversary is not going to attack the block
cipher. They are going to attack the password or some other [weak] part in the
system.
Jeff
On Mon, Sep 8, 2014 at 4:00 PM, Gregory Sloop gr...@sloop.net wrote:
Continuing top posting. [Which doesn't bother me nearly as much as it seems to
bother others... ]
Yes! That was a fantastic answer.
...
[A while later]
So, I need to run this down, but it looks like the easy-rsa script uses 3DES to
do encryption - which seems incredibly foolish when we have aes-256 available.
[Though I suppose 3DES is less computationally expensive for weak processors -
but still a bad trade-off, IMO Actually more reading seems to indicate that
perhaps 3DES is harder for general purpose CPU, but with a smaller key-space.
I'd guess a DES vs. AES specific processor would make DES far more vulnerable
{pulling that guess from, well, you know where... :) }. ]
I think it's safe to assume that 3DES is almost certainly a lousier choice than
AES or Camellia on multiple fronts.
I've posed a question to the OpenVPN folks, about the EasyRSA script, and it
appears easy enough to change the encryption type in the script itself, which
I'll do if they don't.
Well, that was a fruitful question and personal research task. At least I
*know* more about the situation than I did before. It may, or may not, change
the entropy of my passwords, or make me do a lot different in the future - but
even if it doesn't - I'm a lot more knowledgeable about what's going on and can
make informed decisions about how to handle things from here on.
So, thanks to all for your input.
BTW, I especially like:
If they can do a trillion (10^9) decryptions a second, they're still looking at
around 10^22 years to recover the key. *They'll probably get bored before then.*
Sort of like the 3DES vs AES discussion here:
http://security.stackexchange.com/questions/26179/security-comparsion-of-3des-and-aes
...and quote ...
AES uses 128-bit blocks, for a limit of 2^128/2 blocks, i.e. 2^68 bytes, also
known as quite a lot of data
Thanks again!
...
RE: cannot read PEM key file - no start line
Hi Viktor,
Thanks for your response.
I also saw this response from -M. Would this be a problem also?
Cert file or key file? The error indicates that the client can't find the
private key.
Thank you,
Liz
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 5:20 PM
To: openssl-users@openssl.org
Subject: Re: cannot read PEM key file - no start line
On Mon, Sep 08, 2014 at 05:03:58PM -0700, Liz Fall wrote:
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?
No, you can just re-wrap the base64 data you have to 64 characters per line.
There are two different 64's here. The size of the
base64 encoding alphabet (64 possible choices for each letter) and the
length of the PEM encoded line (64 such letters per line).
The file you have is already base64 encoded, but the line length is not PEM
compatible (PEM requires 64 characters per line). So just rewrap the lines
to use 64 chars on all but the last line.
Example: Same (random) base64 data wrapped to 76 characters per line and 64
per line:
$ rand=$(mktemp /tmp/rand.XX)
$ openssl rand 1024 $rand
$ echo; echo 76 per line:
$ $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 57)) 0) {
print encode_base64($buf);
}
'
$ echo; echo 64 per line:
$ $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 48)) 0) {
print encode_base64($buf);
}
'
$ rm -f $rand
76 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+TqSTc
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+UHe9
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQzV6AQLY74Hnjs1sZuuUt
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+L6ju
rWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A16R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZq
LwjOR9M2BPiFPeun22GnlibTK+jzIjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZ
LwjOR9M2BPiFPeun22GnlibTK+C38j
cxH5hLcuvtwev+cpuLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig
cxH5hLcuvtwev+3wtO
kdFZl1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2HQk9ouuKf
wo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM6LhOCD9zGOFxvxC+xYsj
+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWIEMW05cnijpWKdrnrvvFirEeQMnLI
+JemZ
EPxc57WTh9O/vuZDLGm90qa8FwfUkyLGf7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeo
uykVr8gM5uPldKUMA0zdsUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUk
cStshPOGvMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiCTQYa
E+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqcGABBNzUPaDv1
E+MrSYwYbX+kWgP
wcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/MqnaTjJNuoDsm874si3A3Pb7Ib
wcOO+BRyz
021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7
021LN+64cXJ7Yrq+G4V2
jR/WjhlrOei+of89TIaCaSw22vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5En
f5Ccb5rC2E1IQHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciqBscqeNR9WU7C
EwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7UNlKBmrRal3rAIKDIVJIAQ==
64 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlY
fh+TqSTcUHe96FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQ
zV6AQLY74Hnjs1sZuuUtL6jurWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A1
6R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZqLwjOR9M2BPiFPeun22GnlibTK+jz
IjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38jcxH5hLcuvtwev+cp
uLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtOkdFZ
l1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2H
Qk9ouuKfwo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM
6LhOCD9zGOFxvxC+xYsj+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWI
EMW05cnijpWKdrnrvvFirEeQMnLIJemZEPxc57WTh9O/vuZDLGm90qa8FwfUkyLG
f7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeouykVr8gM5uPldKUMA0zd
sUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUkcStshPOG
vMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiC
TQYaE+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqc
GABBNzUPaDv1kWgPwcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/Mq
naTjJNuoDsm874si3A3Pb7IbBRyz021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5
OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2jR/WjhlrOei+of89TIaCaSw2
2vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5Enf5Ccb5rC2E1I
QHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciq
BscqeNR9WU7CEwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7
UNlKBmrRal3rAIKDIVJIAQ==
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
---
This email is free from viruses and malware because avast!
RE: On 2K keys and SHA-256
No complaints from me for 1K or 2K, but...
Oh, sorry, this would be 1.0.2 and HEAD only. Not 1.0.1 or earlier.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: cannot read PEM key file - no start line
Thanks, Viktor.
I have tried to rewrap this cert to 64 per line, but am having difficulties.
I tried to do it in two steps with the first cert and then the second cert,
but each time, I am not getting all of the characters. Can you please help?
Thanks,
Liz
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 5:20 PM
To: openssl-users@openssl.org
Subject: Re: cannot read PEM key file - no start line
On Mon, Sep 08, 2014 at 05:03:58PM -0700, Liz Fall wrote:
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?
No, you can just re-wrap the base64 data you have to 64 characters per line.
There are two different 64's here. The size of the
base64 encoding alphabet (64 possible choices for each letter) and the
length of the PEM encoded line (64 such letters per line).
The file you have is already base64 encoded, but the line length is not PEM
compatible (PEM requires 64 characters per line). So just rewrap the lines
to use 64 chars on all but the last line.
Example: Same (random) base64 data wrapped to 76 characters per line and 64
per line:
$ rand=$(mktemp /tmp/rand.XX)
$ openssl rand 1024 $rand
$ echo; echo 76 per line:
$ $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 57)) 0) {
print encode_base64($buf);
}
'
$ echo; echo 64 per line:
$ $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 48)) 0) {
print encode_base64($buf);
}
'
$ rm -f $rand
76 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+TqSTc
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+UHe9
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQzV6AQLY74Hnjs1sZuuUt
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+L6ju
rWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A16R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZq
LwjOR9M2BPiFPeun22GnlibTK+jzIjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZ
LwjOR9M2BPiFPeun22GnlibTK+C38j
cxH5hLcuvtwev+cpuLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig
cxH5hLcuvtwev+3wtO
kdFZl1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2HQk9ouuKf
wo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM6LhOCD9zGOFxvxC+xYsj
+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWIEMW05cnijpWKdrnrvvFirEeQMnLI
+JemZ
EPxc57WTh9O/vuZDLGm90qa8FwfUkyLGf7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeo
uykVr8gM5uPldKUMA0zdsUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUk
cStshPOGvMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiCTQYa
E+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqcGABBNzUPaDv1
E+MrSYwYbX+kWgP
wcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/MqnaTjJNuoDsm874si3A3Pb7Ib
wcOO+BRyz
021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7
021LN+64cXJ7Yrq+G4V2
jR/WjhlrOei+of89TIaCaSw22vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5En
f5Ccb5rC2E1IQHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciqBscqeNR9WU7C
EwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7UNlKBmrRal3rAIKDIVJIAQ==
64 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlY
fh+TqSTcUHe96FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQ
zV6AQLY74Hnjs1sZuuUtL6jurWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A1
6R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZqLwjOR9M2BPiFPeun22GnlibTK+jz
IjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38jcxH5hLcuvtwev+cp
uLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtOkdFZ
l1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2H
Qk9ouuKfwo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM
6LhOCD9zGOFxvxC+xYsj+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWI
EMW05cnijpWKdrnrvvFirEeQMnLIJemZEPxc57WTh9O/vuZDLGm90qa8FwfUkyLG
f7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeouykVr8gM5uPldKUMA0zd
sUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUkcStshPOG
vMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiC
TQYaE+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqc
GABBNzUPaDv1kWgPwcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/Mq
naTjJNuoDsm874si3A3Pb7IbBRyz021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5
OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2jR/WjhlrOei+of89TIaCaSw2
2vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5Enf5Ccb5rC2E1I
QHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciq
BscqeNR9WU7CEwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7
UNlKBmrRal3rAIKDIVJIAQ==
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
---
This
Re: Hang during SSL /connect - accept
On Mon, Sep 08, 2014 at 05:41:13PM -0700, Norm Green wrote: Thanks Viktor. I did get some fixes (via this list) from Steve a while back because SRP authenication was completely broken out of the box with 1.0.1i. However I don't know if all the changes in the commit you mentioned have been merged. I will investigate further. You'll want at least: 30fbe92 Fix SRP authentication ciphersuites. and then: 03ebf85 Fix SRP ciphersuites. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: cannot read PEM key file - no start line
From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni Sent: Monday, September 08, 2014 08:42 On Sun, Sep 07, 2014 at 07:26:05PM -0700, Liz Fall wrote: I have checked and verified that there is no whitespace. Also, the BEGIN and END statements look correct. However, each line in the cert is 76 chars in length, except for the last line. Should the lines be 64-characters long? Yes. The OpenSSL base64 decoder limits input lines to 64 characters. Nope. The encoder writes 64 (the original PEM spec), but the decoder will accept up to 76 (the less-old MIME spec). As one case I hit often, Java keytool -exportcert writes 76 and openssl reads it just fine. And the error here is no start line. *On Windows* that often occurs when Windows editors treat text files as Unicode/UTF-8 with an invisible BOM (Byte Order Mark) at the beginning of the first line. Try prepending a semantically-meaningless comment line like: Hello! This is my Key!! Rah Rah Go Key Go!! -BEGIN EC PRIVATE KEY- MHcCAQEEIAqD7NQvpg74v7Pik4rAIfk/BIQlQa1fbM9BKkHOkKJBoAoGCCqGSM49 AwEHoUQDQgAE/BR1oMSfz4WgklW7t83E0xClrBh0md1Ata8rsPq8VAsB1WDXPXwk T7WbcXlsyxuyOb7ok8F544xmr+pKreWbHw== -END EC PRIVATE KEY- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate pass phrase brute force...
For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY) just look on the DEK-Info: header line. For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do openssl asn1parse key.pem and the third line will be an OBJECT (really OID) in the form pbeWithhashandcipher. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Monday, September 08, 2014 20:58 snip --On that note: Is there a way to determine from an encrypted key-file what encryption was used to encrypt it? [I have the password, so it doesn't need to be a blind test.]
RE: cannot read PEM key file - no start line
Hi Dave, Thanks for your response. I am running this on Linux. This is what my cert looks like below: What are you saying I should do? Thanks for the clarification. Liz -BEGIN CERTIFICATE- MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCVVMxFDASBgNV BAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcN MDkwNTI4MTgxNzI2WhcNMTkwNTI4MTgxNzI2WjB4MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLV2Vs bHMgRmFyZ28xLDAqBgNVBAsTI1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSUw IwYDVQQDExxXZWxscyBGYXJnbyBFbnRlcnByaXNlIENBIDAyMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAm1mEVgXlHHbd4DrKFIROTf6Q5JwzJEtjFiWN4lQsEvKeVN1p7/ua16c0gFhi zQvuD002pttUG7Tn6uUonUYxJajD2TnykAQu1m5Ks1gisNgYCGzH8tluKeWYANppSRt5F1Is3Yts NOGiYtVFnZf3FejOzVWkhnT5rYXjTf9Osu5KK1Jh7NywbFU5P2ytC4h/M9xnlHuCjy7RBmN956iG 7Eb+BBrvo7ZfTfzWuFzmvficKovoDbZOloLHHsRzj2iQ2euY+xW/g+Zn1lHPQCZfTdLgPUcnV7qp P+1fRVy5hNLQTw3nBrNa5RLIZK8RBpY6kig4wWhyNKP+9Ssc2m34lQIDAQABo4ICMTCCAi0wDwYD VR0TAQH/BAUwAwEB/zCBgwYDVR0gBHwwejA7BgtghkgBhvt7g3QAADAsMCoGCCsGAQUFBwIBFh5o dHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2Nwcy8wOwYLYIZIAYb7e4N0AAEwLDAqBggrBgEFBQcC ARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNvbS9jcHMvMHcGCCsGAQUFBwEBBGswaTAwBggrBgEF BQcwAYYkaHR0cDovL29jc3Atcm9vdC5wa2kud2VsbHNmYXJnby5jb20vMDUGCCsGAQUFBzAChilo dHRwOi8vY3JsLnBraS53ZWxsc2ZhcmdvLmNvbS93Zl9yb290LmNydDAOBgNVHQ8BAf8EBAMCAfYw gbIGA1UdIwSBqjCBp4AUFK8Y973m52vjWvrqUe/+1FpxOcChgYikgYUwgYIxCzAJBgNVBAYTAlVT MRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMgRmFyZ28gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxLzAtBgNVBAMTJldlbGxzIEZhcmdvIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9y aXR5ggQ55JeeMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29t L3Jvb3QuY3JsMB0GA1UdDgQWBBTEq0W2OgsBHGJcyj/H480vMMRX1zANBgkqhkiG9w0BAQUFAAOC AQEALUIw6yFNj7mrTSIuqtT6rsAXgKApylI3HtepbWa6qxEmmDDjCAaOxXZKShTxBQa6qSpYFg0K FxqKsNiot8CAEMxXcapr5OLwytTFvnDSRa9H+mlLT6jpZi8C3fbqEvbVeh7NjT4oj8fNbsf13UgN 0xxlgiez47locWVADdYP/RucG31o+8OqJaZ/+AWsc+B6LoQ9jaYlYaiXXERQopLS8dxTeGp8pvmd YK4ghHG/AwLW0fEcaqQOqrBcf8A+3/RQYEdJ62vZ8Q9T6HwbdPr0zToqeVM5i+DgLjy2fq1eEp6a 5In0N78tkgEr8NPlpPgb93C6T8kNYioQY20dNklqLQ== -END CERTIFICATE- -BEGIN CERTIFICATE- MIID5TCCAs2gAwIBAgIEOeSXnjANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCVVMxFDASBgNV BAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcN MDAxMDExMTY0MTI4WhcNMjEwMTE0MTY0MTI4WjCBgjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC1dl bGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEv MC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVqDM7Jvk0/82bfuUER84A4n135zHCLielTWi5MbqNQ1mX x3Oqfz1cQJ4F5aHiidlMuD+b+Qy0yGIZLEWukR5zcUHESxP9cMIlrCL1dQu3U+SlK93OvRw6esP3 E48mVJwWa2uv+9iWsWCaSOAlIiR5NM4OJgALTqv9i86C1y8IcGjBqAr5dE8Hq6T54oN+J3N0Prj5 OEL8pahbSCOz6+MlsoCultQKnMJ4msZoGK43YjdeUXWoWGPAUe5AeH6orxqg4bB4nVCMe+ez/I4j sNtlAHCEAQgAFG5Uhpq6zPk3EPbg3oQtnaSFN9OH4xXQwReQfhkhahKpdv0SAulPIV4XAgMBAAGj YTBfMA8GA1UdEwEB/wQFMAMBAf8wTAYDVR0gBEUwQzBBBgtghkgBhvt7hwcBCzAyMDAGCCsGAQUF BwIBFiRodHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2NlcnRwb2xpY3kwDQYJKoZIhvcNAQEFBQAD ggEBANIn3ZwKdyu7IvICtUpKkfnRLb7kuxpo7w6kAOnu5+/u9vnldKTC2FJYxHT7zmu1Oyl5GFrv m+0fazbuSCUlFLZWohDo7qd/0D+j0MNdJu4HzMPBJCGHHt8qElNvQRbn7a6U+oxy+hNH8Dx+rn0R OhPs7fpvcmR7nX1/Jv16+yWt6j4pf0zjAFcysLPp7VMX2YuyFA4w6OXVE8Zkr8QA1dhYJPz1j+zx x32l2w8n0cbyQIjmH/ZhqPRCyLk306m+LFZ4wnKbWV01QIroTmMatukgalHizqSQ33ZwmVxwQ023 tqcZZE6St8WRPH9IFmV7Fv3L/PvZ1dZPIWU7Sn9Ho/s= -END CERTIFICATE- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, September 08, 2014 7:29 PM To: openssl-users@openssl.org Subject: RE: cannot read PEM key file - no start line From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni Sent: Monday, September 08, 2014 08:42 On Sun, Sep 07, 2014 at 07:26:05PM -0700, Liz Fall wrote: I have checked and verified that there is no whitespace. Also, the BEGIN and END statements look correct. However, each line in the cert is 76 chars in length, except for the last line. Should the lines be 64-characters long? Yes. The OpenSSL base64 decoder limits input lines to 64 characters. Nope. The encoder writes 64 (the original PEM spec), but the decoder will accept up to 76 (the less-old MIME spec). As one case I hit often, Java keytool -exportcert writes 76 and openssl reads it just fine. And the error here is no start line. *On Windows* that often occurs when Windows editors treat text files as Unicode/UTF-8 with an invisible BOM (Byte Order Mark) at the beginning of the first line. Try prepending a semantically-meaningless comment line like: Hello! This is my Key!! Rah Rah Go Key Go!! -BEGIN EC PRIVATE KEY- MHcCAQEEIAqD7NQvpg74v7Pik4rAIfk/BIQlQa1fbM9BKkHOkKJBoAoGCCqGSM49
Re: cannot read PEM key file - no start line
On Mon, Sep 08, 2014 at 07:44:56PM -0700, Liz Fall wrote: This is what my cert looks like below: What are you saying I should do? Thanks for the clarification. These are the certificates for an intermediate CA and the issuing root CA. Generally, you'd append these to a certificate file with the server certificate as the first entry, and a corresponding private key in some other (not world-readable) file. subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certificate Authorities/CN=Wells Fargo Enterprise CA 02 issuer= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority notBefore=May 28 18:17:26 2009 GMT notAfter=May 28 18:17:26 2019 GMT SHA1 Fingerprint=DD:B1:96:37:D9:9D:EC:8F:05:A2:B1:38:BC:11:D4:AF:ED:0A:BE:39 -BEGIN CERTIFICATE- MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDkwNTI4MTgxNzI2WhcNMTkwNTI4 MTgxNzI2WjB4MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLV2VsbHMgRmFyZ28xLDAq BgNVBAsTI1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSUwIwYD VQQDExxXZWxscyBGYXJnbyBFbnRlcnByaXNlIENBIDAyMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAm1mEVgXlHHbd4DrKFIROTf6Q5JwzJEtjFiWN4lQs EvKeVN1p7/ua16c0gFhizQvuD002pttUG7Tn6uUonUYxJajD2TnykAQu1m5Ks1gi sNgYCGzH8tluKeWYANppSRt5F1Is3YtsNOGiYtVFnZf3FejOzVWkhnT5rYXjTf9O su5KK1Jh7NywbFU5P2ytC4h/M9xnlHuCjy7RBmN956iG7Eb+BBrvo7ZfTfzWuFzm vficKovoDbZOloLHHsRzj2iQ2euY+xW/g+Zn1lHPQCZfTdLgPUcnV7qpP+1fRVy5 hNLQTw3nBrNa5RLIZK8RBpY6kig4wWhyNKP+9Ssc2m34lQIDAQABo4ICMTCCAi0w DwYDVR0TAQH/BAUwAwEB/zCBgwYDVR0gBHwwejA7BgtghkgBhvt7g3QAADAsMCoG CCsGAQUFBwIBFh5odHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2Nwcy8wOwYLYIZI AYb7e4N0AAEwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNv bS9jcHMvMHcGCCsGAQUFBwEBBGswaTAwBggrBgEFBQcwAYYkaHR0cDovL29jc3At cm9vdC5wa2kud2VsbHNmYXJnby5jb20vMDUGCCsGAQUFBzAChilodHRwOi8vY3Js LnBraS53ZWxsc2ZhcmdvLmNvbS93Zl9yb290LmNydDAOBgNVHQ8BAf8EBAMCAfYw gbIGA1UdIwSBqjCBp4AUFK8Y973m52vjWvrqUe/+1FpxOcChgYikgYUwgYIxCzAJ BgNVBAYTAlVTMRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMg RmFyZ28gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxLzAtBgNVBAMTJldlbGxzIEZh cmdvIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5ggQ55JeeMDcGA1UdHwQwMC4w LKAqoCiGJmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29tL3Jvb3QuY3JsMB0G A1UdDgQWBBTEq0W2OgsBHGJcyj/H480vMMRX1zANBgkqhkiG9w0BAQUFAAOCAQEA LUIw6yFNj7mrTSIuqtT6rsAXgKApylI3HtepbWa6qxEmmDDjCAaOxXZKShTxBQa6 qSpYFg0KFxqKsNiot8CAEMxXcapr5OLwytTFvnDSRa9H+mlLT6jpZi8C3fbqEvbV eh7NjT4oj8fNbsf13UgN0xxlgiez47locWVADdYP/RucG31o+8OqJaZ/+AWsc+B6 LoQ9jaYlYaiXXERQopLS8dxTeGp8pvmdYK4ghHG/AwLW0fEcaqQOqrBcf8A+3/RQ YEdJ62vZ8Q9T6HwbdPr0zToqeVM5i+DgLjy2fq1eEp6a5In0N78tkgEr8NPlpPgb 93C6T8kNYioQY20dNklqLQ== -END CERTIFICATE- subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority issuer= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority notBefore=Oct 11 16:41:28 2000 GMT notAfter=Jan 14 16:41:28 2021 GMT SHA1 Fingerprint=93:E6:AB:22:03:03:B5:23:28:DC:DA:56:9E:BA:E4:D1:D1:CC:FB:65 -BEGIN CERTIFICATE- MIID5TCCAs2gAwIBAgIEOeSXnjANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDAxMDExMTY0MTI4WhcNMjEwMTE0 MTY0MTI4WjCBgjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSww KgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0G A1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVqDM7Jvk0/82bfuUER84A4n13 5zHCLielTWi5MbqNQ1mXx3Oqfz1cQJ4F5aHiidlMuD+b+Qy0yGIZLEWukR5zcUHE SxP9cMIlrCL1dQu3U+SlK93OvRw6esP3E48mVJwWa2uv+9iWsWCaSOAlIiR5NM4O JgALTqv9i86C1y8IcGjBqAr5dE8Hq6T54oN+J3N0Prj5OEL8pahbSCOz6+MlsoCu ltQKnMJ4msZoGK43YjdeUXWoWGPAUe5AeH6orxqg4bB4nVCMe+ez/I4jsNtlAHCE AQgAFG5Uhpq6zPk3EPbg3oQtnaSFN9OH4xXQwReQfhkhahKpdv0SAulPIV4XAgMB AAGjYTBfMA8GA1UdEwEB/wQFMAMBAf8wTAYDVR0gBEUwQzBBBgtghkgBhvt7hwcB CzAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2NlcnRw b2xpY3kwDQYJKoZIhvcNAQEFBQADggEBANIn3ZwKdyu7IvICtUpKkfnRLb7kuxpo 7w6kAOnu5+/u9vnldKTC2FJYxHT7zmu1Oyl5GFrvm+0fazbuSCUlFLZWohDo7qd/ 0D+j0MNdJu4HzMPBJCGHHt8qElNvQRbn7a6U+oxy+hNH8Dx+rn0ROhPs7fpvcmR7 nX1/Jv16+yWt6j4pf0zjAFcysLPp7VMX2YuyFA4w6OXVE8Zkr8QA1dhYJPz1j+zx x32l2w8n0cbyQIjmH/ZhqPRCyLk306m+LFZ4wnKbWV01QIroTmMatukgalHizqSQ 33ZwmVxwQ023tqcZZE6St8WRPH9IFmV7Fv3L/PvZ1dZPIWU7Sn9Ho/s= -END CERTIFICATE- -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hang during SSL /connect - accept
This may indeed be the problem, but some of the changes in 1.0.2 do not easily merge back to 1.0.1i. Specifically, this diff seems to have no equivalent code to merge into in 1.0.1i. We may need to consider reverting back to 1.0.1h until 1.0.2 is released. --- a/ssl/s3_lib.c +++ b/ssl/s3_lib.c @@ -3441,8 +3441,10 @@ long ssl3_ctrl(SSL *s, int cmd, long larg, void *parg) cipher = s-s3-tmp.new_cipher; if (!cipher) return 0; - /* No certificate for unauthenticated ciphersuites */ - if (cipher-algorithm_auth SSL_aNULL) + /* No certificate for unauthenticated ciphersuites +* or using SRP authentication +*/ + if (cipher-algorithm_auth (SSL_aNULL|SSL_aSRP)) return 2; cpk = ssl_get_server_send_pkey(s); if (!cpk) Norm On 9/8/2014 7:10 PM, Viktor Dukhovni wrote: On Mon, Sep 08, 2014 at 05:41:13PM -0700, Norm Green wrote: Thanks Viktor. I did get some fixes (via this list) from Steve a while back because SRP authenication was completely broken out of the box with 1.0.1i. However I don't know if all the changes in the commit you mentioned have been merged. I will investigate further. You'll want at least: 30fbe92 Fix SRP authentication ciphersuites. and then: 03ebf85 Fix SRP ciphersuites.
RE: cannot read PEM key file - no start line
Viktor and all:
Thanks for your response.
I am trying to connect to a MongoDB SSL-enable database. This is the API:
#include mongo/util/net/ssl_options.h
#include mongo/client/init.h
int main() {
sslGlobalParams.sslMode.store(SSLGlobalParams::SSLMode_requireSSL);
// only really need a PEM on the server side
mongo::sslGlobalParams.sslPEMKeyFile = path/to/keyfile.pem;
mongo::Status status = mongo::client::initialize();
if (!status.isOK())
::abort();
DBClientConnection c;
c.connect(hostname.whatever.com); // outgoing connections are SSL
}
My question to MongoDB support was: From the code above, the comment states
that there is only a need of a PEM on the server side. What identifies the
key store on the C++ client server? Is as key store not required on the
C++ linux server where my application is running?
MongoDB support response was: That is correct. For encrypted communications
only the MongoDB server needs a PEM file.
I am just not sure what I am supposed to be providing as far as the
sslPEMKeyFile. I have these certificates:
. DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem
. private key of DTCD9C3B2F42757.ent.wfb.bank.corp machine
. certificate for DTCD9C3B2F42757.ent.wfb.bank.corp, signed by WF
Enterprise CA 02
. DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
. WF Enterprise CA 02 certificate, signed by WF Root
. WF Root certificate
Can someone please help clarify this?
Thanks,
Liz
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 7:54 PM
To: openssl-users@openssl.org
Subject: Re: cannot read PEM key file - no start line
On Mon, Sep 08, 2014 at 07:44:56PM -0700, Liz Fall wrote:
This is what my cert looks like below: What are you saying I should do?
Thanks for the clarification.
These are the certificates for an intermediate CA and the issuing root CA.
Generally, you'd append these to a certificate file with the server
certificate as the first entry, and a corresponding private key in some
other (not world-readable) file.
subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certificate Authorities/CN=Wells
Fargo Enterprise CA 02 issuer= /C=US/O=Wells Fargo/OU=Wells Fargo
Certification Authority/CN=Wells Fargo Root Certificate Authority
notBefore=May 28 18:17:26 2009 GMT notAfter=May 28 18:17:26 2019 GMT
SHA1 Fingerprint=DD:B1:96:37:D9:9D:EC:8F:05:A2:B1:38:BC:11:D4:AF:ED:0A:BE:39
-BEGIN CERTIFICATE-
MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v
dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDkwNTI4MTgxNzI2WhcNMTkwNTI4
MTgxNzI2WjB4MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLV2VsbHMgRmFyZ28xLDAq
BgNVBAsTI1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSUwIwYD
VQQDExxXZWxscyBGYXJnbyBFbnRlcnByaXNlIENBIDAyMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAm1mEVgXlHHbd4DrKFIROTf6Q5JwzJEtjFiWN4lQs
EvKeVN1p7/ua16c0gFhizQvuD002pttUG7Tn6uUonUYxJajD2TnykAQu1m5Ks1gi
sNgYCGzH8tluKeWYANppSRt5F1Is3YtsNOGiYtVFnZf3FejOzVWkhnT5rYXjTf9O
su5KK1Jh7NywbFU5P2ytC4h/M9xnlHuCjy7RBmN956iG7Eb+BBrvo7ZfTfzWuFzm
vficKovoDbZOloLHHsRzj2iQ2euY+xW/g+Zn1lHPQCZfTdLgPUcnV7qpP+1fRVy5
hNLQTw3nBrNa5RLIZK8RBpY6kig4wWhyNKP+9Ssc2m34lQIDAQABo4ICMTCCAi0w
DwYDVR0TAQH/BAUwAwEB/zCBgwYDVR0gBHwwejA7BgtghkgBhvt7g3QAADAsMCoG
CCsGAQUFBwIBFh5odHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2Nwcy8wOwYLYIZI
AYb7e4N0AAEwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNv
bS9jcHMvMHcGCCsGAQUFBwEBBGswaTAwBggrBgEFBQcwAYYkaHR0cDovL29jc3At
cm9vdC5wa2kud2VsbHNmYXJnby5jb20vMDUGCCsGAQUFBzAChilodHRwOi8vY3Js
LnBraS53ZWxsc2ZhcmdvLmNvbS93Zl9yb290LmNydDAOBgNVHQ8BAf8EBAMCAfYw
gbIGA1UdIwSBqjCBp4AUFK8Y973m52vjWvrqUe/+1FpxOcChgYikgYUwgYIxCzAJ
BgNVBAYTAlVTMRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMg
RmFyZ28gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxLzAtBgNVBAMTJldlbGxzIEZh
cmdvIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5ggQ55JeeMDcGA1UdHwQwMC4w
LKAqoCiGJmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29tL3Jvb3QuY3JsMB0G
A1UdDgQWBBTEq0W2OgsBHGJcyj/H480vMMRX1zANBgkqhkiG9w0BAQUFAAOCAQEA
LUIw6yFNj7mrTSIuqtT6rsAXgKApylI3HtepbWa6qxEmmDDjCAaOxXZKShTxBQa6
qSpYFg0KFxqKsNiot8CAEMxXcapr5OLwytTFvnDSRa9H+mlLT6jpZi8C3fbqEvbV
eh7NjT4oj8fNbsf13UgN0xxlgiez47locWVADdYP/RucG31o+8OqJaZ/+AWsc+B6
LoQ9jaYlYaiXXERQopLS8dxTeGp8pvmdYK4ghHG/AwLW0fEcaqQOqrBcf8A+3/RQ
YEdJ62vZ8Q9T6HwbdPr0zToqeVM5i+DgLjy2fq1eEp6a5In0N78tkgEr8NPlpPgb
93C6T8kNYioQY20dNklqLQ==
-END CERTIFICATE-
subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells
Fargo Root Certificate Authority issuer= /C=US/O=Wells Fargo/OU=Wells Fargo
Certification Authority/CN=Wells Fargo Root Certificate Authority
notBefore=Oct 11 16:41:28 2000 GMT notAfter=Jan 14 16:41:28 2021 GMT
SHA1 Fingerprint=93:E6:AB:22:03:03:B5:23:28:DC:DA:56:9E:BA:E4:D1:D1:CC:FB:65
-BEGIN CERTIFICATE-
Re: cannot read PEM key file - no start line
On Mon, Sep 08, 2014 at 08:14:32PM -0700, Liz Fall wrote: I am trying to connect to a MongoDB SSL-enable database. This is the API: // only really need a PEM on the server side mongo::sslGlobalParams.sslPEMKeyFile = path/to/keyfile.pem; The comment is highly misleading. PEM is a meta format. It encapsulates base64 encoded blobs between BEGIN/END headers/trailers, allowing multiple objects to be concatenated unambiguously and transported undamaged via ASCII email. This this is a client, what goes here is likely a client certificate chain and a client private key, or just NULL, if client certificates are not employed (you're likely authenticating the client with a username and password instead). -- BEGIN RSA PRIVATE KEY - private key for client cert base64 encoded -- END RSA PRIVATE KEY - client cert base64 encoded -- END CERTIFICATE - -- BEGIN CERTIFICATE - intermediate issuer base64 encoded -- END CERTIFICATE - ... -- BEGIN CERTIFICATE - root issuer base64 encoded -- END CERTIFICATE - I would try NULL first. You may need to separately specify a CAfile, or CApath for validating the server certificate. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
