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:
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
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
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
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.
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
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-
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
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
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:
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:
---
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. :)
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
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
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:
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
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)
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
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 =
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
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);
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
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
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
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
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
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
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
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);
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
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,
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
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
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
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.
--
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
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
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,
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
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
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,
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
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
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��
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:
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
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
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.
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
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
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
+++
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
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
53 matches
Mail list logo
