[openssl-users] IPv6 and OpenSSL at the BIO level -- should it work?
I have a colleague who is using OpenSSL 1.0.1j and BIOs to connect to servers. Given the requirement that his software must now connect to IPv6 addresses, still using the BIO interface, is it supposed to work? That is, can a BIO caller pass a string hostname:port like this [2620:0:170:28a1::1003]:443 to BIO and have it work? I see a reference to Patch #1365 which deals with openssl s_client and doing left-side truncation of an IPv6 address specified in the -connect option. The discussion of this patch is http://rt.openssl.org/Ticket/Display.html?id=1365user=guestpass=guest but it looks like it's a patch for the application, not the BIO. In fact in the plain build of 1.0.1j I have with OPENSSL_USE_IPV6 specified, still has this left-side truncation issue (I see code in crypto/apps/s_socket.c:extract_host_port() which simply looks for a colon and takes what's on the right side for the port, assuming the left side is a dotted decimal IPv4 address. I have already suggested to this colleague that the issue with IPv6 is name and address resolution, not socket I/O. If he handles the name resolution himself, creates a socket with the right address family and sockaddr format, and then uses the right BIO calls, it should work. We do our own name/address handling and don't use BIO in my application so I have never studied how to do it there. Thanks for your advice Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] IPv6 and OpenSSL at the BIO level -- should it work?
Hi Rich. Excellent. That's exactly what I thought.Thank you very much. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich Sent: Thursday, January 29, 2015 12:14 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] IPv6 and OpenSSL at the BIO level -- should it work? IPv6 support is sketchy and incomplete and being worked on, albeit slowly. Doing all DNS and accept, etc., on your own and just passing an open socket descriptor to create a socket BIO should all just work fine. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others
Thanks again. I had returned to the conf_def.c file and saw the logic that
essentially summarizes your detailed sequence.
The workaround you suggested of specifying OPENSSL_CONF is a variation of what
I had given our QA team (the original reporter of the issue on AIX), and this
indeed circumvented the issue.
Thanks to all for all the interest in and traffic on this question.
Dave
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Michael Wojcik
Sent: Thursday, January 22, 2015 5:34 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes
failure on AIX, warning on all others
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf Of Salz, Rich
Sent: Thursday, January 22, 2015 16:37
To: openssl-users@openssl.org
Subject: Re: [openssl-users] missing default
/usr/local/ssl/openssl.cnf causes failure on AIX, warning on all
others
I can't. The behavior of fopen is defined by ISO 9899 and the Single
UNIX Specfication, which AIX has adhered to for well over a decade.
I meant no disrespect to big blue :) I worked there for a
half-decade, and also with them on standards for a lot longer...
int main(void) {fopen(/usr/local/ssl/openssl.cnf, rb);
perror(fopen);
And what happens if some of the directories on the path don't exist?
Depends on which of the following happens first:
- open(2) encounters a missing directory: ENOENT.
- open(2) encounters a non-traversable directory: EACCES. (I wrote EPERM in
an earlier note, but I don't think that's even a real errno value name. Duh.)
- open(2) gets all the way to the file but doesn't have sufficient permission:
ENOENT.
- Some other I/O error occurs (broken NFS mount, etc): some other errno value,
or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets fopen set
EACCES, EINTR (if open is slow and gets interrupted by a signal), EISDIR,
ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should only happen for
file creation), ENOTDIR (if you have a non-directory as a non-terminal path
component), ENXIO (trying to open a special node in an unsupported way),
EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY.
A quick look at apps/openssl.c suggests that it'll abort if it gets anything
other than CONF_R_NO_SUCH_FILE from ERR_GET_REASON(ERR_peek_last_error()) after
NCONF_load fails. That doesn't clarify things much, though I'd suggest that it
might be worth suppressing this behavior via an option.
If the user knows there's no configuration file, the following should work
(under suitable shells):
OPENSSL_CONF=/dev/null openssl ...
Just let openssl open /dev/null as its config file. It'll get EOF immediately
(as if openssl.cnf existed and was empty) and should trundle along happily.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others
Thanks again. I had returned to the conf_def.c file and saw the logic that
essentially summarizes your detailed sequence.
The workaround you suggested of specifying OPENSSL_CONF is a variation of what
I had given our QA team (the original reporter of the issue on AIX), and this
indeed circumvented the issue.
Thanks to all for all the interest in and traffic on this question.
Dave
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Michael Wojcik
Sent: Thursday, January 22, 2015 5:34 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes
failure on AIX, warning on all others
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf Of Salz, Rich
Sent: Thursday, January 22, 2015 16:37
To: openssl-users@openssl.org
Subject: Re: [openssl-users] missing default
/usr/local/ssl/openssl.cnf causes failure on AIX, warning on all
others
I can't. The behavior of fopen is defined by ISO 9899 and the Single
UNIX Specfication, which AIX has adhered to for well over a decade.
I meant no disrespect to big blue :) I worked there for a
half-decade, and also with them on standards for a lot longer...
int main(void) {fopen(/usr/local/ssl/openssl.cnf, rb);
perror(fopen);
And what happens if some of the directories on the path don't exist?
Depends on which of the following happens first:
- open(2) encounters a missing directory: ENOENT.
- open(2) encounters a non-traversable directory: EACCES. (I wrote EPERM in
an earlier note, but I don't think that's even a real errno value name. Duh.)
- open(2) gets all the way to the file but doesn't have sufficient permission:
ENOENT.
- Some other I/O error occurs (broken NFS mount, etc): some other errno value,
or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets fopen set
EACCES, EINTR (if open is slow and gets interrupted by a signal), EISDIR,
ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should only happen for
file creation), ENOTDIR (if you have a non-directory as a non-terminal path
component), ENXIO (trying to open a special node in an unsupported way),
EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY.
A quick look at apps/openssl.c suggests that it'll abort if it gets anything
other than CONF_R_NO_SUCH_FILE from ERR_GET_REASON(ERR_peek_last_error()) after
NCONF_load fails. That doesn't clarify things much, though I'd suggest that it
might be worth suppressing this behavior via an option.
If the user knows there's no configuration file, the following should work
(under suitable shells):
OPENSSL_CONF=/dev/null openssl ...
Just let openssl open /dev/null as its config file. It'll get EOF immediately
(as if openssl.cnf existed and was empty) and should trundle along happily.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others
Thanks very much. Most appreciated. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Wojcik Sent: Thursday, January 22, 2015 4:16 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others (Apologies for the top-post; Outlook does not deal properly with HTML email.) If open, called by fopen, actually is setting EPERM, then one of the following should be true: - /usr/local/ssl/openssl.cnf exists but the user does not have read permission on it - Either /usr/local or /usr/local/ssl exists and is a directory, but the user does not have *execute* permission on it [[Dave] ] I believe this is the case; the x bit was not on /usr/local I think. I no longer have access to the host (owned by someone else). Note that *read* permission on the directories is not necessary to open a file contained therein. Read permission on a directory is only required to enumerate the directory contents (for ls, find, etc). Execute permission on a directory, on the other hand, is traversal permission, and you need traversal permission along the path to open a file. There are some other possibilities, such as ACLs (not commonly used in AIX, but available). Users who don't have traverse permission for /usr itself would have a hard time getting this far, so we can probably rule that out. A run under truss might be enlightening. [[Dave] ] oh yeah, I had thought of trying truss. From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of mclellan, dave Sent: Thursday, January 22, 2015 15:00 To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others Thank you Rich. The sentence you couldn't understand is my bad, s/b: In fact, on some, even non-AIX hosts, permissions would suggest that the permission error should be returned. Dave This message has been scanned for malware by Websense. www.websense.comhttp://www.websense.com/ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others
Hi. I'm running openssl CLI 1.0.1j (for example) on a bunch of different unix
platforms. On all of them, the default missing /usr/local/ssl/openssl.cnf
causes a warning, but the CLI continues to initialize and opens the command
line. We've known about this behavior since first incorporating 1.0.1c years
ago); this is no big deal.
Except for AIX: on all our AIX machines of varying versions, the missing
/usr/local/ssl/openssl.cnf raises a permission error, and openssl CLI refuses
to run.
openssl version
1152921504606846944:error:0200100D:system library:fopen:Permission
denied:bss_file.c:169:fopen('/usr/local/ssl/openssl.cnf','rb')
1152921504606846944:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:174:
1152921504606846944:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:199:
None of the hosts we've visited have /usr/local/ssl, not to mention the actual
default file. In fact, on some, even non-AIX hosts, permissions would suggest
that the permission should be returned.
Should this be happening? Is AIX simply less forgiving, and returns a more
serious error. Or is the openssl CLI handling the missing file differently on
AIX?
Thanks for any enlightenment shareable.
Dave
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others
Thank you Rich. The sentence you couldn't understand is my bad, s/b: In fact, on some, even non-AIX hosts, permissions would suggest that the permission error should be returned. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich Sent: Thursday, January 22, 2015 1:22 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others None of the hosts we've visited have /usr/local/ssl, not to mention the actual default file. In fact, on some, even non-AIX hosts, permissions would suggest that the permission should be returned. Not sure what that last sentence means. Should this be happening? Is AIX simply less forgiving, and returns a more serious error. Or is the openssl CLI handling the missing file differently on AIX? I can well believe that AIX is, exactly that, less forgiving and returns different error codes than many other Unices. There is no AIX-specific code in openssl around file access. Trying ls -ld on /usr and /usr/local and /usr/local/ssl and checking errno might be interesting. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
RE: openssl SSL3 vulnerability
Now we’re talking.Thank you Jay Foster.SSL_get_version() call does show
what I expect given a variety of combinations of capabilities of the peers
communicating. Examples:
Ø It shows “TLSv1” where the server has disabled SSLv3, and the client is
too old to support TLSv1.2, using, for example, DHE-RSA-AES128-SHA
Ø It show “TLSV1.2” when both the server and client have disabled SSLv3, and
the cipher suite is, for example, DHE-RSA-AES128-GCM-SHA256
Having now understood this part (using the correct function to print the
protocol version): once I turn off SSLv3, TLSv1 and TLSv1.1, and THEN try to
connect with an old client (using 0.9.8r), I now get the ‘unknown protocol’
message I expect.
Thanks to all who contributed to this thread. I hope Pradeep got the answer he
needed (since he started this in the first place).
Dave
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Jay Foster
Sent: Friday, October 24, 2014 1:43 PM
To: openssl-users@openssl.org
Subject: Re: openssl SSL3 vulnerability
There seems to be a difference between the SSL (protocol) version and the
Cipher version/description. You might try the following debug code to clarify.
printf(SSL Version: %s\n, SSL_get_version(ssl));
const SSL_CIPHER *ciph = SSL_get_current_cipher(ssl);
if (ciph)
{
printf(Cipher Version : %s\n, SSL_CIPHER_get_version(ciph));
printf(Cipher Name: %s\n, SSL_CIPHER_get_name(ciph));
}
For example:
SSL Version: TLSv1
Cipher Version : TLSv1/SSLv3
Cipher Name: AES256-SHA
From the SSL_CIPHER_get_name(3) man page:
SSL_CIPHER_get_version() returns string which indicates the SSL/TLS protocol
version that first defined the cipher. This is currently SSLv2 or TLSv1/SSLv3.
In some cases it should possibly return ``TLSv1.2'' but does not; use
SSL_CIPHER_description() instead.
Jay
On 10/24/2014 10:16 AM, mclellan, dave wrote:
The plot thickens, but our mails must be crossing. I do indeed see TLSV1.2 in
that message, but if and only if a much more restrictive set of ciphers is
specified. That's why I was questioning the appearance of SSLv3 in other
cases, despite the case that I had set the options to disable SSLv3.
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.commailto:dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
-Original Message-
From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Erik Forsberg
Sent: Friday, October 24, 2014 12:46 PM
To: openssl-users@openssl.orgmailto:openssl-users@openssl.org
Subject: Re: openssl SSL3 vulnerability
That triggers my memory. I saw this too a long time ago, if I recall correctly,
if you get a TLSv1.2 connection, its still logged as SSLv3 (there is lack of
printable enums in the OpenSSL code. I looked at my negotiation with wireshark
and saw that I got TLSv1.2 despite what the debug trace said.
I hope this could be fixed one day ?
-- Original Message --
On 24/10/2014 15:53, Pradeep Gudepu wrote:
To my earlier code, I have added these extra flags for client:
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_NO_SSLv3);
And server also has these same flags set, so that no way client and server can
communicate on sslv2, sslv3.
But again in logs I see SSL3 is negotiated:
[2014-10-24 18:00:17.063, Info proxysrv:10684] SSLConfig::Init: SSL
initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Mon Oct 20 15:08:32 2014).
[2014-10-24 18:02:11.640, Info proxysrv:10684] SSLSocket::Callback:
Handshake done: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256)
Mac=SHA1
Does this really mean SSLv3.0 protocol negotiated?
Or does it just mean SSLv3.x (which includes TLSv1.x)?
Or perhaps SSLv3 compatible cipher suite (which also includes TLSv1.x)?
On server, I have these ciphers set:
::SSL_CTX_set_cipher_list(ctx,
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM);
Is there something wrong with these ciphers? What are best cipher argument for
only TLSv1 communication. I think, I need not set ciphers on client side.
Thanks – Pradeep reddy.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This
public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
RE: openssl SSL3 vulnerability
I have also had this same experience (1.0.1i) with SSLv3 being negotiated
though I used the SSL_OP_NO_SSLv3 flag on the SSL_set_options call. (I have NOT
re-built with SSLv3 disabled).
What I expected to see is 'unknown protocol' when an SSLv3 client tries to
connect to my server with the options call coded as above. (server would be
configured to refuse SSLv3)
The only way I found to eliminate SSLv3 from negotiation was to insist on a
cipher suite that is TLS only. But in that case, I get 'no shared cipher'
during negotiation.
Any advice is helpful. Thanks.
Dave
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Pradeep Gudepu
Sent: Friday, October 24, 2014 6:13 AM
To: openssl-users@openssl.org
Subject: openssl SSL3 vulnerability
Hi,
To Get rid of openssl SSL3 Poodle bug, I upgraded from openssl 1.0.1g to
1.0.1j. Also Compiled openssl sources with no-ssl2 no-ssl3, so that only TLSv1
works in client server application.
On top of this, in my SSL config code, I added following code to create context.
if(server)
//method = ::SSLv23_server_method();
method = ::TLSv1_server_method();
else
//method = ::SSLv23_client_method();
method = ::TLSv1_client_method();
if(server)
{
::SSL_CTX_set_options(ctx, (SSL_OP_NO_SSLv2 |
SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION));
::SSL_CTX_set_cipher_list(ctx,
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM);
}
But in logs, I still see, client and server are negotiated with SSLv3.
SSLConfig::Init: SSL initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Fri Oct 24
07:44:36 2014).
SSLSocket::Callback: Handshake done: AES256-SHA SSLv3 Kx=RSA
Au=RSA Enc=AES(256) Mac=SHA1
SocketClose: shutdown failed ('WSAENOTCONN: A request to send or receive data
was disallowed because the socket is not connected and (when sending on a
datagram socket using a sendto call) no address was supplied.').
Also I see, connection is not established
Can you please tell me, is any more code I have to add, such that only TLSv1 is
negotiated.
Thanks - Pradeep Reddy.
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and
other defects.
RE: openssl SSL3 vulnerability
If that's the case (Jeffrey has not observed the behavior) then I have done something wrong, which has been my suspicion anyway. But it seemed pretty straightforward. Should simply setting the SSL_OP_NO_SSLv3 flag take care of it? I have done this both on the CTX and the session level. At CTX init we do this: Ø sslv23_method() Ø SSL_CTX_new() Ø ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2) at session init: Ø SSL_new() Ø ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2) Ø this is lab code – will be dependent on server configuration to disable SSLv3 based on customer’s compatibility needs. Thanks again. +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Friday, October 24, 2014 8:42 AM To: OpenSSL Users List Subject: Re: openssl SSL3 vulnerability On Fri, Oct 24, 2014 at 7:15 AM, mclellan, dave dave.mclel...@emc.commailto:dave.mclel...@emc.com wrote: I have also had this same experience (1.0.1i) with SSLv3 being negotiated though I used the SSL_OP_NO_SSLv3 flag on the SSL_set_options call. (I have NOT re-built with SSLv3 disabled). If that's the case, then a security related defect should be filed at https://www.openssl.org/support/rt.html. I have to qualify it with if that's the case because I use those same options, and I have not observed the behavior. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.orgmailto:openssl-users@openssl.org Automated List Manager majord...@openssl.orgmailto:majord...@openssl.org
RE: openssl SSL3 vulnerability
ARGH! Good catch.Yes the second one is a typo -- the code shows SSLv3 for the second flag. s/b: copy and paste didn’t work so I had to re-fatfinger. #0;. sslv23_method() #0;. SSL_CTX_new() #0;. ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3) at session init: #0;. SSL_new() #0;. ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3) #0;. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Michael Wojcik Sent: Friday, October 24, 2014 9:30 AM To: openssl-users@openssl.org Subject: RE: openssl SSL3 vulnerability You have SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 there. I assume v2 ... v2 is a typo, but if that's what your code actually has, then that's the problem. (Assuming there isn't some other problem, of course.) Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of mclellan, dave Sent: Friday, 24 October, 2014 09:06 To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: RE: openssl SSL3 vulnerability If that's the case (Jeffrey has not observed the behavior) then I have done something wrong, which has been my suspicion anyway. But it seemed pretty straightforward. Should simply setting the SSL_OP_NO_SSLv3 flag take care of it? I have done this both on the CTX and the session level. At CTX init we do this: #0;. sslv23_method() #0;. SSL_CTX_new() #0;. ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2) at session init: #0;. SSL_new() #0;. ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2) #0;. this is lab code – will be dependent on server configuration to disable SSLv3 based on customer’s compatibility needs. Thanks again. +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Friday, October 24, 2014 8:42 AM To: OpenSSL Users List Subject: Re: openssl SSL3 vulnerability On Fri, Oct 24, 2014 at 7:15 AM, mclellan, dave dave.mclel...@emc.commailto:dave.mclel...@emc.com wrote: I have also had this same experience (1.0.1i) with SSLv3 being negotiated though I used the SSL_OP_NO_SSLv3 flag on the SSL_set_options call. (I have NOT re-built with SSLv3 disabled). If that's the case, then a security related defect should be filed at https://www.openssl.org/support/rt.html. I have to qualify it with if that's the case because I use those same options, and I have not observed the behavior. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.orgmailto:openssl-users@openssl.org Automated List Manager majord...@openssl.orgmailto:majord...@openssl.org Click herehttps://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to report this email as spam. This message has been scanned for malware by Websense. www.websense.comhttp://www.websense.com/
RE: openssl SSL3 vulnerability
Aha, that’s an interesting point: Or does it just mean SSLv3.x (which includes TLSv1.x)? Or perhaps SSLv3 compatible cipher suite (which also includes TLSv1.x)? The reason I questioned my own setup, and piggy-backed on Pradeep’s first post was this: I expected to see “TLS” when such a protocol is chosen. There is a case where I specifically see TLSv1.2 in the cipher text string similar to what is shown in the ‘Handshake done: message from Pradeep’s output. Specifically, if both sides use, for example, DHE-RSA-AES128-GCM-SHA256, I see “TLSv1.2”. The place I’m trying to get to is: 1. New version of software, customer configures to disable SSLv3 2. New version of client, which supports TLS is able to connect to server 3. Old version of client, which doesn’t support TLS, gets rejected – we expect this. Thanks to all for your continued input on this thread. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: Friday, October 24, 2014 12:37 PM To: openssl-users@openssl.org Subject: Re: openssl SSL3 vulnerability On 24/10/2014 15:53, Pradeep Gudepu wrote: To my earlier code, I have added these extra flags for client: SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); And server also has these same flags set, so that no way client and server can communicate on sslv2, sslv3. But again in logs I see SSL3 is negotiated: [2014-10-24 18:00:17.063, Info proxysrv:10684] SSLConfig::Init: SSL initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Mon Oct 20 15:08:32 2014). [2014-10-24 18:02:11.640, Info proxysrv:10684] SSLSocket::Callback: Handshake done: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 Does this really mean SSLv3.0 protocol negotiated? Or does it just mean SSLv3.x (which includes TLSv1.x)? Or perhaps SSLv3 compatible cipher suite (which also includes TLSv1.x)? On server, I have these ciphers set: ::SSL_CTX_set_cipher_list(ctx, ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM); Is there something wrong with these ciphers? What are best cipher argument for only TLSv1 communication. I think, I need not set ciphers on client side. Thanks – Pradeep reddy. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
RE: openssl SSL3 vulnerability
The plot thickens, but our mails must be crossing. I do indeed see TLSV1.2 in
that message, but if and only if a much more restrictive set of ciphers is
specified. That's why I was questioning the appearance of SSLv3 in other
cases, despite the case that I had set the options to disable SSLv3.
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Forsberg
Sent: Friday, October 24, 2014 12:46 PM
To: openssl-users@openssl.org
Subject: Re: openssl SSL3 vulnerability
That triggers my memory. I saw this too a long time ago, if I recall correctly,
if you get a TLSv1.2 connection, its still logged as SSLv3 (there is lack of
printable enums in the OpenSSL code. I looked at my negotiation with wireshark
and saw that I got TLSv1.2 despite what the debug trace said.
I hope this could be fixed one day ?
-- Original Message --
On 24/10/2014 15:53, Pradeep Gudepu wrote:
To my earlier code, I have added these extra flags for client:
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_NO_SSLv3);
And server also has these same flags set, so that no way client and server
can communicate on sslv2, sslv3.
But again in logs I see SSL3 is negotiated:
[2014-10-24 18:00:17.063, Info proxysrv:10684] SSLConfig::Init:
SSL initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Mon Oct 20 15:08:32
2014).
[2014-10-24 18:02:11.640, Info proxysrv:10684]
SSLSocket::Callback: Handshake done: AES256-SHA SSLv3 Kx=RSA
Au=RSA Enc=AES(256) Mac=SHA1
Does this really mean SSLv3.0 protocol negotiated?
Or does it just mean SSLv3.x (which includes TLSv1.x)?
Or perhaps SSLv3 compatible cipher suite (which also includes TLSv1.x)?
On server, I have these ciphers set:
::SSL_CTX_set_cipher_list(ctx,
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM);
Is there something wrong with these ciphers? What are best cipher argument
for only TLSv1 communication. I think, I need not set ciphers on client side.
Thanks – Pradeep reddy.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This
public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
cipher list experiments - what's preventing ECDHE?
I'm doing some experimentation with cipher lists using OpenSSL 1.0.1h. I have two peers using the same libraries, and both enabled with these suites in the call to SSL_set_cipher_list(): 1. ECDHE-ECDSA-AES128-GCM-SHA256 2. ECDHE-RSA-AES128-GCM-SHA256 3. DHE-RSA-AES128-GCM-SHA256 These are shown by the 'openssl ciphers' command using the same libraries. I have specified each of these individually to try out each one independently of the others. Neither of the ECDHE ciphers (1 and 2 above) are chosen by my two peers, and the result is 'no shared cipher' when either of these is specified. Cipher 3 is chosen successfully, so it seems that the failing component is the elliptic curve modifier of DHE. If it's in the supported list, what is preventing ECDHE from being used? What am I missing to use the ECDHE- suites? How can I track down where my mistake is? Thanks for whatever guidance is offered. +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+-
RE: cipher list experiments - what's preventing ECDHE?
Thanks Jeff for your answers also.I got 1.0.1h from openssl.org/downloads
with the associated MD5 and SHA checksums. TLS 1.2 is definitely enabled
because I get it with the 3rd cipher suite.
We don't do any EC set in our code like what I see in s_server.c.I think
that's our issue.
Dave
+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546,
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Jeffrey Walton
Sent: Thursday, June 26, 2014 9:31 AM
To: OpenSSL Users List
Subject: Re: cipher list experiments - what's preventing ECDHE?
On Thu, Jun 26, 2014 at 8:51 AM, mclellan, dave dave.mclel...@emc.com wrote:
I’m doing some experimentation with cipher lists using OpenSSL 1.0.1h. I
have two peers using the same libraries, and both enabled with these
suites in the call to SSL_set_cipher_list():
1. ECDHE-ECDSA-AES128-GCM-SHA256
2. ECDHE-RSA-AES128-GCM-SHA256
3. DHE-RSA-AES128-GCM-SHA256
These are shown by the ‘openssl ciphers’ command using the same libraries.
I have specified each of these individually to try out each one
independently of the others.
Neither of the ECDHE ciphers (1 and 2 above) are chosen by my two
peers, and the result is ‘no shared cipher’ when either of these is specified.
Cipher 3 is chosen successfully, so it seems that the failing
component is the elliptic curve modifier of DHE.
The server needs an ECDSA key and certifcate to provide ECDSA. Its not clear if
you have it.
I'm not sure why ECDHE-RSA-AES128-GCM-SHA256 is not selected. Perhaps
TLS1.2 is not available? Lack of TLS 1.2 would explain both
ECDHE-ECDSA-AES128-GCM-SHA256 and ECDHE-RSA-AES128-GCM-SHA256. I know Ubuntu
*prior* to 14 disabled it out of the box (via OPENSSL_NO_TLS1_2_CLIENT). And it
was disabled by default in Java 7 and earlier.
Where did you get your copy of 1.0.1h? Is it distro provided? Are you
accidentally linking against a distro provided OpenSSL?
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: cipher list experiments - what's preventing ECDHE?
Aha.I see the instrumentation in s_server.c which causes EC to be enabled. We're not doing any of this part yet. Thanks very much for the pointer. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, June 26, 2014 9:29 AM To: openssl-users@openssl.org Subject: Re: cipher list experiments - what's preventing ECDHE? On Thu, Jun 26, 2014, mclellan, dave wrote: I'm doing some experimentation with cipher lists using OpenSSL 1.0.1h. I have two peers using the same libraries, and both enabled with these suites in the call to SSL_set_cipher_list(): 1. ECDHE-ECDSA-AES128-GCM-SHA256 2. ECDHE-RSA-AES128-GCM-SHA256 3. DHE-RSA-AES128-GCM-SHA256 These are shown by the 'openssl ciphers' command using the same libraries. I have specified each of these individually to try out each one independently of the others. Neither of the ECDHE ciphers (1 and 2 above) are chosen by my two peers, and the result is 'no shared cipher' when either of these is specified. Cipher 3 is chosen successfully, so it seems that the failing component is the elliptic curve modifier of DHE. If it's in the supported list, what is preventing ECDHE from being used? What am I missing to use the ECDHE- suites? How can I track down where my mistake is? Thanks for whatever guidance is offered. Are you setting the ECDH parameters in the server? If no ECDH parameters are set then all ECDHE ciphersuites are disabled. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: cipher list experiments - what's preventing ECDHE?
Thank you Viktor, and Jeff, and Dr. Steve. +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Thursday, June 26, 2014 9:46 AM To: OpenSSL Users List Subject: Re: cipher list experiments - what's preventing ECDHE? On Thu, Jun 26, 2014 at 09:30:49AM -0400, Jeffrey Walton wrote: 1. ECDHE-ECDSA-AES128-GCM-SHA256 2. ECDHE-RSA-AES128-GCM-SHA256 3. DHE-RSA-AES128-GCM-SHA256 The server needs an ECDSA key and certifcate to provide ECDSA. Its not clear if you have it. Only for 1. I'm not sure why ECDHE-RSA-AES128-GCM-SHA256 is not selected. Typically, no ECDH parameters set with SSL_CTX_set_tmp_ecdh(). Given RedHat and others shipping only P-256 and P-384, the most interoperable choice is to use one of these two. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: State of EBCDIC support in OpenSSL
We are active and continuing users of the z/OS port of OpenSSL, have just rebuilt 1.0.1c without heartbeats on a maintenance stream and are upgrading to 1.0.g on a future release stream. Just as example of staying current on z/OS. We use z/OS on the server side only, and generates server certs from a Windows machine, and transfer the certs to USS using binary FTP. The server does not require a client cert since we couldn't get that working and have never had time to look into it. We don't use the openssl CLI on z/OS. We have even considered the port for Fujitsu BS2000 but don't have a business priority for it. All this to say that we sure hope that z/OS and OpenSSL continue to be real, and I'm glad to have read Tim's response. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Stephan Mühlstrasser Sent: Tuesday, April 29, 2014 4:48 AM To: Tim Hudson; openssl-users@openssl.org Subject: Re: State of EBCDIC support in OpenSSL Am 29.04.14 10:28, schrieb Tim Hudson: Bug reports on EBCDIC with patches are definitely interesting as there is an active community of OpenSSL z/OS users - at the very least the other users will benefit from any work you have already done. I can provide bug reports, but at the moment I cannot promise that I can come up with corresponding patches as well. I did some research in the OpenSSL mailing list archives, and from that I have the impression that there's little activity from OpenSSL z/OS users over the last few years. Are there other places where you see the active community of OpenSSL z/OS users? For the broader context I think you'll find the issue for handling such platforms will usually be the typical one of regular platform access. Checking, adjusting, and confirming patches which are platform specific that are non-trivial basically requires access to the platform. One thing to consider is if you (or anyone else) is able to provide permanent (or semi-permanent) access (via ssh) to a z/OS platform with USS installed that places the user into a standard shell environment with the compilers accessible. I'm sorry, but I can't help with platform access, as we only have a z/OS development system for porting our software, not even a real zSeries machine. I would expect that IBM itself should be interested in a working OpenSSL port for zSeries. We have a very old version of OpenSSL on our system that we downloaded from the IBM website in the past. This version is for example able to print out certificates correctly. Today the IBM website about open source software available for z/OS point to openssl.org for getting OpenSSL: http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html The free unsupported version of OpenSSL previously offered here is no longer available. Instead, we refer you to the functionally equivalent version available from the official OpenSSL project website. If someone from IBM is reading this, please consider the request by Tim for access to a z/OS platform. Stephan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl 1.0.1g MD5 and SHA1 mismatch
I searched the archives (having recalled something about this over the last three weeks) but found no specific answer. After download of the .gz file for OpenSSL 1.0.g and the MD5 and SHA1 files, I have found that the actual MD5 over the .gz doesn't match the downloaded checksum, nor does the SHA1 value. At the moment I'm using an earlier version (1.0.1c) of the openssl md5 and sha1 commands to check them. Such checksum values match for 1.0.1e and 1.01.c and the 0.9.8 stream. Are there replacements for the md5 and sha1 files that I'm missing? Thanks. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+-
RE: openssl 1.0.1g MD5 and SHA1 mismatch
Mea Culpa. I had a bad 1.0.1g gzip file. Having found the right gzip file, both MD5 and SHA1 match now. For those who answered off-list, thanks very much. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- From: mclellan, dave Sent: Monday, April 28, 2014 10:18 AM To: openssl-users@openssl.org Subject: openssl 1.0.1g MD5 and SHA1 mismatch I searched the archives (having recalled something about this over the last three weeks) but found no specific answer. After download of the .gz file for OpenSSL 1.0.g and the MD5 and SHA1 files, I have found that the actual MD5 over the .gz doesn't match the downloaded checksum, nor does the SHA1 value. At the moment I'm using an earlier version (1.0.1c) of the openssl md5 and sha1 commands to check them. Such checksum values match for 1.0.1e and 1.01.c and the 0.9.8 stream. Are there replacements for the md5 and sha1 files that I'm missing? Thanks. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+-
Looking more at the Heatbleed
We are looking more deeply into Heartbleed to determine the risk to our proprietary, non-open application. 1. Background summary: Our proprietary client/server protocol is protected by TLS with OpenSSL 1.0.1c and 1.0.1e. We do not respond to http or any other standard protocols. The session initiation and RPC-like communication between client and server is encapsulated inside an API library which an application can't influence directly. Neither the physical socket nor the SSL object that represents the channel is directly accessible to the caller of the API library. 2. Question: Heartbeat negotiation: Is there anything automatic in TLS session negotiation that causes the heartbeat protocol to be used by peers without application awareness? Our application does nothing explicit to negotiate the Heartbeat Extension; we do nothing to prevent it. 3. Question: Heartbeat use: once negotiated, is there anything automatic in the protocol that causes one side to request a heartbeat from the peer? Our peers communicate at the application level in a strict synchronous request - response method; a client thread sends a request and waits for a response; no secondary threads are involved. Since we enclose the application client and server applications and we do no heartbeat work ourselves, what is the risk? We recognize that reverse engineering our protocol is possible, but we believe that the difficulty of the exploit in the context of our server application is very high. We also recognize that we could be surprised by very clever attackers, so we want to do the right thing. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+-
CVE 2014-0160 -- disabling the heartbeat
Hi all. There are two mitigations possible for the recently discovered Heartbleed attack. Ø Upgrade to 1.0.1g, released yesterday with a fix Ø Recompile a vulnerable release with -DOPENSSL_NO_HEARTBEATS Suppose we choose the latter. We might be installed into a server host in a shop with an earlier release of our software on the clients. Is it an issue if the server refuses to do heartbeats but the client expects to use them? or is there a negotiation element that determines their shared capability WRT heartbeats? Thanks. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+-
RE: CVE 2014-0160 -- disabling the heartbeat
True that’s possible, except that it only applies if customers actually install a corrected older version that we make available. We can pour the clean water but can’t make the customer drink it; he might still be drinking the dirty water. Thanks for that suggestion. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- From: Alan Buxey [mailto:a.l.m.bu...@lboro.ac.uk] Sent: Tuesday, April 08, 2014 2:00 PM To: openssl-users@openssl.org; mclellan, dave Subject: Re: CVE 2014-0160 -- disabling the heartbeat ...or take the upstream fix...apply to your older version and keep the heartbeat functionality. Which is what I believe the very latest redhat/centos patches do Alan
RE: CVE 2014-0160 -- disabling the heartbeat
Thank you. In the meantime, I found RFC 6520 which explains it. Most appreciated. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Michael Tuexen Sent: Tuesday, April 08, 2014 2:43 PM To: openssl-users@openssl.org Subject: Re: CVE 2014-0160 -- disabling the heartbeat On 08 Apr 2014, at 19:19, mclellan, dave dave.mclel...@emc.com wrote: Hi all. There are two mitigations possible for the recently discovered Heartbleed attack. Ø Upgrade to 1.0.1g, released yesterday with a fix Ø Recompile a vulnerable release with -DOPENSSL_NO_HEARTBEATS Suppose we choose the latter. We might be installed into a server host in a shop with an earlier release of our software on the clients. Is it an issue if the server refuses to do heartbeats but the client expects to use them? or is there a negotiation element that determines their shared capability WRT heartbeats? Support is negotiated as part of the TLS handshake. So the client has always to deal with the case that the server doesn't support it or does not allow the client to send Heartbeats. Best regards Michael Thanks. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e with FIPS 2.0 and Visual Studio 2012 -- has anyone made this work for Win32?
Hi Dr. Henson. Thanks for your reply. I will take a look at newer snapshots. We have two different deployments we are working with, one which links statically against the librypto and libssl, and second one which links statically (with a wrapper library which we are using /fixed with). The certificate signature is SHA1 with RSA. The subject public key is RSA 1024. Thanks for your advice. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Tuesday, February 25, 2014 5:14 PM To: openssl-users@openssl.org Subject: Re: OpenSSL 1.0.1e with FIPS 2.0 and Visual Studio 2012 -- has anyone made this work for Win32? On Tue, Feb 25, 2014, mclellan, dave wrote: Very high level question: We are using OpenSSL 1.0.1e with FIPS 2.0 and VS2012. Our Windows 64 bit proprietary client/server with SSL works fine, as do all our Linux platforms (FIPS only in use on Windows and Linux). In Win32 we are seeing: 1. Intermittent FIPS_mode_set failures - fingerprint doesn't match Try a recent 1.0.1 snapshot. The use of /fixed might resolve this. 2. When FIPS_mode_set() works, we get certificate signature validation errors. More details on request. Is the certificate using an unapproved algorithms like MD5? If not please give more details. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 1.0.1e with FIPS 2.0 and Visual Studio 2012 -- has anyone made this work for Win32?
Very high level question: We are using OpenSSL 1.0.1e with FIPS 2.0 and VS2012. Our Windows 64 bit proprietary client/server with SSL works fine, as do all our Linux platforms (FIPS only in use on Windows and Linux). In Win32 we are seeing: 1. Intermittent FIPS_mode_set failures - fingerprint doesn't match 2. When FIPS_mode_set() works, we get certificate signature validation errors. More details on request. Is anyone using this combination successfully in Win32-bit configurations? Thanks +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.commailto:dave.mclel...@emc.com +-+-+-+-+-+-+-+-+-
RE: Interoperability question
Ok fair enough. I don't *think* it's possible to plug in some arbitrary other crypto, except through the Engine interface. But there are others on the list that actually know something about that, and I can claim only that I know how to spell the word engine. Good luck. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomson, Duncan Sent: Friday, September 13, 2013 9:10 PM To: openssl-users@openssl.org Subject: RE: Interoperability question For reasons I can't go into, it is mandatory that we use Microsoft's Cryptography Next Generation (CNG) on Windows. (That's not a decision I have any control over.) If OpenSSL can use CNG for it's crypto functions, then that would probably work for us. Is that possible? Duncan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of mclellan, dave Sent: Friday, September 13, 2013 11:48 AM To: openssl-users@openssl.org Subject: RE: Interoperability question Is there a reason you don't want to use OpenSSL on windows? I'd say that would be pretty interoperable -- or more appropriately: it would make your source the same (roughly) for Windows and Linux. Humbly suggested... +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Thomson, Duncan Sent: Friday, September 13, 2013 1:50 PM To: openssl-users@openssl.org Subject: Interoperability question Sorry if this is a dumb question, but I did a little searching and looked at the FAQ, and didn't find an answer, so hope you all won't mind if I post it here. I want to use TLS with an AES cypher to secure client/server communications for my application. I will be building versions of my app for both Windows and Linux. On Windows I might use the Schannel API which in turn I believe will use CNG for encryption. I want to choose the right libraries to use on Linux for maximum interoperability. Would openssl be a good choice? Thanks in advance for any hints. Duncan ___ ___ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org ___ ___ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Interoperability question
Is there a reason you don't want to use OpenSSL on windows? I'd say that would be pretty interoperable -- or more appropriately: it would make your source the same (roughly) for Windows and Linux. Humbly suggested... +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomson, Duncan Sent: Friday, September 13, 2013 1:50 PM To: openssl-users@openssl.org Subject: Interoperability question Sorry if this is a dumb question, but I did a little searching and looked at the FAQ, and didn't find an answer, so hope you all won't mind if I post it here. I want to use TLS with an AES cypher to secure client/server communications for my application. I will be building versions of my app for both Windows and Linux. On Windows I might use the Schannel API which in turn I believe will use CNG for encryption. I want to choose the right libraries to use on Linux for maximum interoperability. Would openssl be a good choice? Thanks in advance for any hints. Duncan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
repost: OpenSSL 1.0.1E and FIPS 2.0.x?
Sorry for the re-post, I thought someone would have some authoritative answer, opinion, or experience with this subject of compatibility and FIPS approval status when upgrading... From: mclellan, dave Sent: Thursday, June 20, 2013 12:42 PM To: openssl-users@openssl.org Subject: OpenSSL 1.0.1E and FIPS 2.0.x? I've searched archives for an answer, but found nothing obvious - if we move from OpenSSL 1.0.1c (with FIPS OM 2.0) to OpenSSL 1.0.1e, do we also have to move ahead to latest version of FIPS OM which appears to be 2.0.4? Thanks +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
RE: repost: OpenSSL 1.0.1E and FIPS 2.0.x?
Excellent. Thank you very much. very helpful and is exactly what we need to know. Dave +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+ -Original Message- From: Steve Marquess [mailto:marqu...@opensslfoundation.com] Sent: Tuesday, June 25, 2013 2:59 PM To: openssl-users@openssl.org Cc: mclellan, dave Subject: Re: repost: OpenSSL 1.0.1E and FIPS 2.0.x? On 06/25/2013 01:48 PM, mclellan, dave wrote: Sorry for the re-post, I thought someone would have some authoritative answer, opinion, or experience with this subject of compatibility and FIPS approval status when upgrading... From: mclellan, dave Sent: Thursday, June 20, 2013 12:42 PM To: openssl-users@openssl.org Subject: OpenSSL 1.0.1E and FIPS 2.0.x? I've searched archives for an answer, but found nothing obvious - if we move from OpenSSL 1.0.1c (with FIPS OM 2.0) to OpenSSL 1.0.1e, do we also have to move ahead to latest version of FIPS OM which appears to be 2.0.4? From the perspective of the validity of the OpenSSL FIPS Object Module 2.0 validation, all other software including OpenSSL is out of scope of the validation. So policy isn't a constraint on your choice of OpenSSL version and/or revision, only technical compatibility. The 2.0 FIPS module was designed to be compatible with the OpenSSL 1.0.1 release (including all letter revisions), and hopefully also the upcoming 1.0.2 release. The letter revisions with OpenSSL 1.0.1 (the most recent being 1.0.1e) address bug and security fixes, so you'll want the latest revision. In the DoD and federal government arena security policies will usually require such upgrades. The revisions of the FIPS module (the most recent being 2.0.5) are primarily for the purpose of adding support for new platforms. We incorporate the occasional minor bugfix when we can, but the fixes (including security fixes) we'd most like to include we usually can't due to the substantial restrictions on modifications to validated modules. So, there is no reason to upgrade to the latest 2.0 FIPS module revision unless the specific platform(s) of interest require that revision. If you're building a FIPS module for the first time you might as well use the latest revision, but all earlier revisions 2.0, 2.0.1, etc. remain fully valid. To summarize: always use the latest 1.0.1n revision of OpenSSL, but once you have built and fielded a specific revision 2.0.N of the FIPS module there is no reason to upgrade it even when upgrading to OpenSSL 1.0.1n. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 1.0.1E and FIPS 2.0.x?
I've searched archives for an answer, but found nothing obvious - if we move from OpenSSL 1.0.1c (with FIPS OM 2.0) to OpenSSL 1.0.1e, do we also have to move ahead to latest version of FIPS OM which appears to be 2.0.4? Thanks +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
OpenSSL/FIPS Object Module and FIPS compliance - testing some assertions
We are starting our FIPS implementation soon (FIPS OM 2.0 and OpenSSL 1.0.1) and I'd like to test out this set of assumptions (or maybe they are 'assertions') - In the context of OpenSSL, FIPS compliance is all about algorithm choice. In FIPS mode (FIPS_mode_set() returns success), weaker algorithms are disabled and OpenSSL returns an error if use of them is attempted in FIPS mode. - As long as one side of the connection insists that FIPS-approved algorithms be used, and as long as the other side is capable and agrees, then the two negotiate only a FIPS-approved algorithm. o Both sides might be implemented with OpenSSL, but only one of them has to be running in FIPS mode for the negotiation to choose a FIPS algorithm. o If one side is not implemented with OpenSSL, the same is still true: as long as it can negotiate a shared cipher with an process running in FIPS-mode, FIPS compliance is still achieved. - Technically the phrase 'FIPS compliant' refers to the software capability; it does not describe the quality of an end-to-end connection. That is, if a running program is 'FIPS-compliant' it will insure that a safe connection will be negotiated, where 'safe connection' means 'a connection using a FIPS-approved algorithm'. Having written these, they now seem like dumb questions, but I'd rather have affirmation of assertions and appear dumb than do the wrong thing based on a wrong assumption. Thanks for your advice (Steve...) +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
RE: OpenSSL/FIPS Object Module and FIPS compliance - testing some assertions
Thank you for this answer, and by the way to all others who have answered, and thanks in advance to all who might still.I'm now getting a better picture from the variety of answers. Apologies again for the repeated post (due to a problem with my subscription to openssl-users) +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+ From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Erik Tkal Sent: Thursday, November 15, 2012 10:17 AM To: openssl-users@openssl.org Subject: RE: OpenSSL/FIPS Object Module and FIPS compliance - testing some assertions The term 'FIPS compliant' does not refer to the software capability, but to the implementation used to perform the cryptographic operations. If only one end of your connection is in FIPS mode then the full end to end path is not necessarily FIPS compliant. In fact, without some out-of-band mechanism there is no way to determine what implementation is being used on the other end since the wire protocol is the same. Otherwise the most you can say is that your end of the connection is FIPS compliant. You can still utilize FIPS approved algorithms without guaranteeing FIPS compliance. Erik Tkal Juniper OAC/UAC/Pulse Development From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of mclellan, dave Sent: Tuesday, November 13, 2012 4:26 PM To: openssl-users@openssl.org Subject: OpenSSL/FIPS Object Module and FIPS compliance - testing some assertions We are starting our FIPS implementation soon (FIPS OM 2.0 and OpenSSL 1.0.1) and I'd like to test out this set of assumptions (or maybe they are 'assertions') - In the context of OpenSSL, FIPS compliance is all about algorithm choice. In FIPS mode (FIPS_mode_set() returns success), weaker algorithms are disabled and OpenSSL returns an error if use of them is attempted in FIPS mode. - As long as one side of the connection insists that FIPS-approved algorithms be used, and as long as the other side is capable and agrees, then the two negotiate only a FIPS-approved algorithm. o Both sides might be implemented with OpenSSL, but only one of them has to be running in FIPS mode for the negotiation to choose a FIPS algorithm. o If one side is not implemented with OpenSSL, the same is still true: as long as it can negotiate a shared cipher with an process running in FIPS-mode, FIPS compliance is still achieved. - Technically the phrase 'FIPS compliant' refers to the software capability; it does not describe the quality of an end-to-end connection. That is, if a running program is 'FIPS-compliant' it will insure that a safe connection will be negotiated, where 'safe connection' means 'a connection using a FIPS-approved algorithm'. Having written these, they now seem like dumb questions, but I'd rather have affirmation of assertions and appear dumb than do the wrong thing based on a wrong assumption. Thanks for your advice (Steve...) +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
OpenSSL/FIPS Object Module and FIPS compliance - testing some assertions
[If this is posted a 2nd time, my apologies, I believe my subscription was broken] We are starting our FIPS implementation soon (FIPS OM 2.0 and OpenSSL 1.0.1) and I'd like to test out this set of assumptions (or maybe they are 'assertions') - In the context of OpenSSL, FIPS compliance is all about algorithm choice. In FIPS mode (FIPS_mode_set() returns success), weaker algorithms are disabled and OpenSSL returns an error if use of them is attempted in FIPS mode. - As long as one side of the connection insists that FIPS-approved algorithms be used, and as long as the other side is capable and agrees, then the two negotiate only a FIPS-approved algorithm. o Both sides might be implemented with OpenSSL, but only one of them has to be running in FIPS mode for the negotiation to choose a FIPS algorithm. o If one side is not implemented with OpenSSL, the same is still true: as long as it can negotiate a shared cipher with an process running in FIPS-mode, FIPS compliance is still achieved. - Technically the phrase 'FIPS compliant' refers to the software capability; it does not describe the quality of an end-to-end connection. That is, if a running program is 'FIPS-compliant' it will insure that a safe connection will be negotiated, where 'safe connection' means 'a connection using a FIPS-approved algorithm'. Having written these, they now seem like dumb questions, but I'd rather have affirmation of assertions and appear dumb than do the wrong thing based on a wrong assumption. Thanks for your advice (Steve M...) +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
RE: OpenSSL/FIPS Object Module and FIPS compliance - testing some assertions
Thanks for that clarification. It's not so cut and dry, I see.
About this: ... and don't even bother to build fipscanister.o... Then on what
grounds could they claim FIPS compliance?
Dave
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Jeffrey Walton
Sent: Wednesday, November 14, 2012 3:57 PM
To: openssl-users@openssl.org
Subject: Re: OpenSSL/FIPS Object Module and FIPS compliance - testing some
assertions
On Wed, Nov 14, 2012 at 3:25 PM, mclellan, dave dave.mclel...@emc.com wrote:
...
We are starting our FIPS implementation soon (FIPS OM 2.0 and OpenSSL 1.0.1)
and I’d like to test out this set of assumptions (or maybe they are
‘assertions’)
- In the context of OpenSSL, FIPS compliance is all about algorithm
choice. In FIPS mode (FIPS_mode_set() returns success), weaker algorithms
are disabled and OpenSSL returns an error if use of them is attempted in
FIPS mode.
- As long as one side of the connection insists that FIPS-approved
algorithms be used, and as long as the other side is capable and agrees,
then the two negotiate only a FIPS-approved algorithm.
This is not entirely correct. Its algorithm and application. For
example, MD5 is withdrawn so its no longer a FIPS approved algorithm
per se. However, its still allowed in SSL/TLS where its used as a PRF
(without the need for collision resistance). The MD5 and SSL/TLS
exemption is stated in NIST Special Publication 800-90.
The TLS 1.0 and 1.1 KDF is approved when the following
conditions are satisfied:
(1) The TLS 1.0 and 1.1 KDF is performed in the context
of the TLS protocol.
(2) SHA-1 and HMAC are as specified in FIPS 180-3 and
198-1, respectively.
Note that MD5 and HMAC-MD5 shall not be used as a general
hash function or HMAC function, respectively.
FIPS compliance/acceptance testing is another can of worms. I've been
in shops where the folks claim to be FIPS based on OpenSSL, yet they
don't even bother to build fipscanister.o. Sigh
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
re: how to extract O= and OU= from a subject cert
Got it. thanks very much. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of lists Sent: Thursday, October 04, 2012 12:01 PM To: openssl-users@openssl.org Subject: We know how to extract the subject and issuer from a cert sent by a peer. Can anyone point out where we get started to look into how to extract the Organization and organizationalUnit attributes? It’s not obvious from the API definitions and I’ve been searching the openssl-users archive but I am not finding hits that clearly identify this. Quick and dirty, man x509, look for the -nameopt option and read about the TEXT OPTIONS. Look at the corresponding flags in starting from apps/x509.c code: you can obtain the subject with parts split by \n (line feeds) and that makes easier to search for \nOU= and alike. Not the best solution but quick. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: how to extract O= and OU= from a subject cert
Thank you Dr. Henson. Got it. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, October 04, 2012 12:22 PM To: openssl-users@openssl.org Subject: Re: how to extract O= and OU= from a subject cert On Wed, Oct 03, 2012, mclellan, dave wrote: We know how to extract the subject and issuer from a cert sent by a peer. Can anyone point out where we get started to look into how to extract the Organization and organizationalUnit attributes? It's not obvious from the API definitions and I've been searching the openssl-users archive but I am not finding hits that clearly identify this. Check out the manual pages for the X509_NAME functions in particular X509_NAME_get_index_by_NID. Then X509_NAME_ENTRY_get_data and possibly ASN1_STRING_to_UTF8. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
how to extract O= and OU= from a subject cert
We know how to extract the subject and issuer from a cert sent by a peer. Can anyone point out where we get started to look into how to extract the Organization and organizationalUnit attributes? It's not obvious from the API definitions and I've been searching the openssl-users archive but I am not finding hits that clearly identify this. Thanks for whatever kickstart you can provide. +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
RE: a couple of newbie questions regarding ssl lib
I'm far from an expert, but your flow below seems mostly right. What you describe is how we have used SSL in our application. We do not use BIOs for a number of reasons, one of which is that we have an existing non-SSL application over which we laid SSL. The initial sequence of system calls (that is, accept and connect, initial handshake) is followed by the SSL sequences. BIOs seemed unnecessary for our situation, but I can see where there are scenarios where BIOs are the cool way to go. Also, when I last looked, using BIOs seemed to preclude IPv6 addressing. So using raw system calls followed by SSLconnect/accept could be done without regard to IP protocol. The SSL protocol is well-defined and books describe many aspects of it. Google SSL and TLS and you'll find the good ones. If you really need to care about the connect/accept state machine (do you really?) FWIW. Dave McLellan - Consulting Software Engineer Storage Platforms, Enablers, and Applications EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng Sent: Saturday, November 19, 2005 1:46 PM To: openssl-users@openssl.org Subject: a couple of newbie questions regarding ssl lib dear all: i am new to the open ssl library, after a couple of days source code reading, my understanding is that one can either use bio (come with the open ssl lib) or standard socket interface to connect ssl protocol to the underlying tcp protocol, if i would like to use standard socket to do that, the basic flow is as follows: as tcp client: socket --- connect (blocked!) --- SSL_new --- SSL_write SSL_set_fd SSL_read (blocked!) SSL_connect (blocked!) as tcp server: socket --- accept (blocked!) --- SSL_new--- SSL_write bind SSL_set_fd SSL_read (blocked!) listen SSL_accept (blocked!) the SSL_connect/SSL_accept implement a (pretty complicate) state machine that is used to do the ssl handshaking, for that purpose, these two functions are blocked multiple times on the underlying socket id. after SSL_connect/SSL_accept returns, the corresponding ssl link is established and ready for io. in the io phase, SSL_read will again be blocked on the undelying socket id until data for that link is available. the questions i have are: 1. do i understand right? 2. if my understanding is correct, standard socket works pretty well in this picture. why we still need bio? what are things that the bio can do and the standard socket can not? 3. anybody know if there is any doc available about the state machines implemented in SSL_connect/SSL_accept? thanks a lot. chong peng __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: a couple of newbie questions regarding ssl lib
Woops. What I meant instead of Google is Amazon - they, along with many other booksellers have the good ones. Here are two that helped me: O'Reilly (John Viega): Network Security with OpenSSL Eric Recorla's: SSL and TLS: Desinging and Building Secure Systems FWIW2 Dave McLellan - Consulting Software Engineer Storage Platforms, Enablers, and Applications EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mclellan, dave Sent: Saturday, November 19, 2005 3:46 PM To: 'openssl-users@openssl.org' Subject: RE: a couple of newbie questions regarding ssl lib I'm far from an expert, but your flow below seems mostly right. What you describe is how we have used SSL in our application. We do not use BIOs for a number of reasons, one of which is that we have an existing non-SSL application over which we laid SSL. The initial sequence of system calls (that is, accept and connect, initial handshake) is followed by the SSL sequences. BIOs seemed unnecessary for our situation, but I can see where there are scenarios where BIOs are the cool way to go. Also, when I last looked, using BIOs seemed to preclude IPv6 addressing. So using raw system calls followed by SSLconnect/accept could be done without regard to IP protocol. The SSL protocol is well-defined and books describe many aspects of it. Google SSL and TLS and you'll find the good ones. If you really need to care about the connect/accept state machine (do you really?) FWIW. Dave McLellan - Consulting Software Engineer Storage Platforms, Enablers, and Applications EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng Sent: Saturday, November 19, 2005 1:46 PM To: openssl-users@openssl.org Subject: a couple of newbie questions regarding ssl lib dear all: i am new to the open ssl library, after a couple of days source code reading, my understanding is that one can either use bio (come with the open ssl lib) or standard socket interface to connect ssl protocol to the underlying tcp protocol, if i would like to use standard socket to do that, the basic flow is as follows: as tcp client: socket --- connect (blocked!) --- SSL_new --- SSL_write SSL_set_fd SSL_read (blocked!) SSL_connect (blocked!) as tcp server: socket --- accept (blocked!) --- SSL_new--- SSL_write bind SSL_set_fd SSL_read (blocked!) listen SSL_accept (blocked!) the SSL_connect/SSL_accept implement a (pretty complicate) state machine that is used to do the ssl handshaking, for that purpose, these two functions are blocked multiple times on the underlying socket id. after SSL_connect/SSL_accept returns, the corresponding ssl link is established and ready for io. in the io phase, SSL_read will again be blocked on the undelying socket id until data for that link is available. the questions i have are: 1. do i understand right? 2. if my understanding is correct, standard socket works pretty well in this picture. why we still need bio? what are things that the bio can do and the standard socket can not? 3. anybody know if there is any doc available about the state machines implemented in SSL_connect/SSL_accept? thanks a lot. chong peng __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL_set_fd Question
The SSL socket and the raw socket are not two different physical descriptors. By using SSL_set_fd you are merely associating the file descriptor with the higher level SSL protocol. SSL needs the physical socket you created to do its own I/O on. My application (previously non-SSL enabled, we added SSL to it) has exactly the same configuration: a socket produced by a regular socket() or accept() call, which is then linked to an SSL session. But the original descriptor must not be closed, as far as I know. you could do some encapsulation of the socket descriptor and the SSL session. Or: you don't have to remember the socket descriptior until close time: you can use SSL_get_fd() call to retrieve the descriptor at that time; then you call close() with the retrieved value. I haven't tried this but it looks like it will work. like perhaps: newSocket = accept(); newSSLSocket = NewSSLSocket(); SSL_set_fd( newSSLSocket, newSocket ); . do stuff with SSL socket s = SSL_get_fd(newSSLsocket); SSL_shutdown( newSSLScoket); close( s ); Dave Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry L. Jones Sent: Friday, November 18, 2005 10:09 AM To: openssl-users@openssl.org Subject: SSL_set_fd Question hello, In my code I have a normal socket and I am using SSL_set_fd to turn it into an SSL socket. After I have make it an SSL socket I no longer need or want to the original socket. I have tried closing it after the SSL_set_fd but this make the SSL socket no good. What I want is to have only one socket reference to manage and close when my process is done. I don't want to keep track of both the normal socket and the SSL socket for closing in the end. I have tried closing the SSL socket after it has been set but this does not close the original socket. Currently working code flow: newSocket = accept(); newSSLSocket = NewSSLSocket(); SSL_set_fd( newSSLSocket, newSocket ); . do stuff with SSL socket SSL_shutdown( newSSLScoket) close( newSocket ); I would like a flow like this if possible ( this flow does not work I am not allowed to close the original socket): newSocket = accept(); newSSLSocket = NewSSLSocket(); SSL_set_fd( newSSLSocket, newSocket ); close( newSocket ); . do stuff with SSL socket SSL_shutdown( newSSLScoket); I would welcome any suggestions. Thanks, Perry __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Has anybody built and used OpenSSL on IBM zLinux?
Title: Using Java to communicate to C++ program in SSL My product builds and uses OpenSSL on z/Linux. There's not any magic really. I didn't do anything different for z/Linux than for any other Linux. Details off-list if you're interested, or if other participants want to know, we can stay on-list. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fan, ZhenqiangSent: Thursday, September 29, 2005 6:56 PMTo: 'openssl-users@openssl.org'Subject: Has anybody built and used OpenSSL on IBM zLinux? Hi, Has anybody built and used OpenSSL on IBM zLinux? Thanks, Zhenqiang Fan -Original Message-From: Fan, Zhenqiang [mailto:[EMAIL PROTECTED] Sent: Thursday, September 29, 2005 9:01 AMTo: 'openssl-users@openssl.org'Cc: Fan, ZhenqiangSubject: Using Java to communicate to C++ program in SSL Hi, Is it possible to use JSSE (Java Secure Socket Extension) to talk to a C++ program using OpenSSL? Can anybody share your experience with me if you have done so? Thanks, Zhenqiang Fan
RE: Has anybody built and used OpenSSL on IBM zLinux?
Aside from the old version issues, you would want to build and distribute it yourself, if you want to make sure you're running what you tested; this is why we did it. Plus if there are any tweaks in the build you need (we made minor linker option changes), then you have to build it yourself anyway. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Sent: Friday, September 30, 2005 5:24 AM To: openssl-users@openssl.org Subject: Re: Has anybody built and used OpenSSL on IBM zLinux? Hi, didn't used it yet, but OpenSSL seems to work. Why do want to build it yourself, usally openssl is part of a distribution?! I looked at one of our zLinux installations - there is an OpenSSL 0.9.6g (not the freshest, is it ;-)) Sebastian Fan, Zhenqiang wrote: Hi, Has anybody built and used OpenSSL on IBM zLinux? Thanks, Zhenqiang Fan -Original Message- *From:* Fan, Zhenqiang [mailto:[EMAIL PROTECTED] *Sent:* Thursday, September 29, 2005 9:01 AM *To:* 'openssl-users@openssl.org' *Cc:* Fan, Zhenqiang *Subject:* Using Java to communicate to C++ program in SSL Hi, Is it possible to use JSSE (Java Secure Socket Extension) to talk to a C++ program using OpenSSL? Can anybody share your experience with me if you have done so? Thanks, Zhenqiang Fan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Getting sockaddr_in structures from a BIO or SSL struct.
Cross-platform portability: excellent reason. As long as OpenSSL is everywhere you need it to be, this is a great reason. OpenSSL isn't everywhere we needed it, but we had a portable socket library that is. We buried SSL handling inside of that; using SSL where supported and customer chooses it, not using it where we can't. BIOs looked really cool and useful to me. I'm still looking for an implementation opportunity. DaveMclellan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas J. Hruska Sent: Sunday, June 26, 2005 10:08 PM To: openssl-users@openssl.org Subject: Re: Getting sockaddr_in structures from a BIO or SSL struct. mclellan, dave wrote: Unless you have a specific reason to use BIOs, you can do a regular accept() Typical reason to use BIOs: Cross-platform portability. I recommend using BIOs whenever someone uses the pre-built Win32 OpenSSL Installation Project binaries and they have difficulties. Using BIOs in terms of sockets is generally not needed because socket handles tend to be process global compatable under most OSes whereas FILE *'s are typically local module compatable only. Thomas Hruska __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Getting sockaddr_in structures from a BIO or SSL struct.
Unless you have a specific reason to use BIOs, you can do a regular accept() and use the socket and sockaddr_in from its return. Do whatever you want with the sockaddr_in. The socket returned by accept() is input to the SSL_set_fd to associate it with an SSL from SSL_new(). Then later, you would do an SSL_accept(SSL) to satisfy the expected client SSL_connect(). In my own application, which added SSL over top of (or should I say underneath) an existing application protocol, we do a lot of system call work before we figure out that SSL should be involved. When we figure that out, it is simple to glue the socket to the SSL and keep going with SSL taking over from there. FWIW. Dave McLellan - Consulting Software Engineer EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Santapau Sent: Sunday, June 26, 2005 2:11 PM To: openssl-users@openssl.org Subject: Getting sockaddr_in structures from a BIO or SSL struct. Hello All, Is there a way in the OpenSSL API that allows you to save connection information from a BIO_do_accept() on a socket like accept() does ?, specifically a sockaddr_in structure, or similar. If not, I am going to try to populate a BIO or SSL structure using information from a standard accept() call and then use the API to populate a BIO for the completetion of an SSL_accept(), is this safe ? caveats ? Thanks All, __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Recommended SSL Books...
two excellent sources: O'Reilly: "Network Security using OpenSSL" by Viega, Messier, and Chandra Addison-Wesley: "SSL and TLS" by Rescorla Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Monday, June 06, 2005 12:22 PMTo: openssl-users@openssl.orgSubject: Recommended SSL Books... I have been using OpenSSL for about a month and though I have a basic understanding I know there is much more to learn. I have leveraged several resources on the web regarding SSL and I am looking for recommendations on good SSL Books - preferably both as a programmers guide and reference book. Thanks in advance for any suggestions, Ron MuckSenior Software Engineer[EMAIL PROTECTED]503.579.1414 x5054www.nobeltec.com
RE: Beginner Question
Agreed: Both are excellent and essential. use the man pages in www.openssl.org/docs also. There are many specifics there that you'll need to know eventually. I found I had to dig into the openssl source to work through some nasty problems (not OpenSSL problems, programmer airheadedness), so don't rule that out. Dave Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Koenning Sent: Tuesday, March 01, 2005 4:28 PM To: openssl-users@openssl.org Subject: Re: Beginner Question Ragnar Paulson wrote: I'm looking for a pointer to more documentation of how to use the openssl API, I don't really want to read the source or learn the internals. I have found the following two references: SSL and TLS: Designing and Building Secure Systems by Eric Rescorla Network Security with OpenSSL: Cryptography for Secure Communications by John Viega, Matt Messier, and Pravir Chandra Which of these should I buy, or is there a more recommened alternative. Both, because the latter book doesn't explain the details of the SSL/TLS protocol, but recommends reading the first book. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Dual 64 32 libraries
We are using OpenSSL on four Unix platforms and four Linux flavors including AMD64 in 64 and 32 bit modes. But we are building separate sets of libraries. I don't know how else you can do it. Let's go off list if you want to pursue. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Somerville Sent: Tuesday, January 25, 2005 1:54 AM To: openssl-users@openssl.org Subject: Dual 64 32 libraries Hello I need to configure, build, and install both 64 and 32 bit libraries on 64 bit platforms that support both sizes. I can't find any documentation on how to do this. In this list I've found a hint that ./config -m32 might help but this gives errors on a Linux AMD_64 system. I think the errors may be due to both -m32 and -m64 being passed to the compiler/assembler. Also any suggestions on how and where the installed libraries should be placed in the system diectories would be appreciated. Thanks Bill __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL error: no cipher list
On my first SSL implementation, I struggled with this specific error. The Diffie-Hellman parameters for key exchange must be initialized, and if I remember correctly they weren't in my case. You must set up a callback to your code where it initializes DH parms. Call SSL_CTX_set_tmp_dh_callback to establish your callback. In order to see what to do inside it, visit the www.openssl.org/docs/ssl/ssl.html. There's an example here: http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html# I hope this doesn't steer you off the course. Dave McLellan - Consulting Software Engineer EMC Corporation 228 South St. Hopkinton MA 01748 phone: 508-249-1257 fax 508-497-8030 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henry Su Sent: Friday, January 21, 2005 3:11 PM To: openssl-users@openssl.org Subject: RE: SSL error: no cipher list No sure if you have set it or not. If not, you can try following example: #define CIPHER_LIST ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) ; -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Yuriy Synov Sent: Friday, January 21, 2005 6:15 AM To: openssl Subject: SSL error: no cipher list Dear All, I get this error with one POP3 server when I call function SSL_connect: error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list Could someone tell me what it means and how I can get rid of it? TIA Best regards, Yuriy Synov. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
test post - delete this
Title: test post - delete this testing email rejection please delete this email, I'm testing my ability to post, which has been broken for a whilt. sorry for the bother. d.
RE: Secure and non secure connection
Hi: This must be common for an existing c/s application to which SSL must be added. This is exactly what we faced earlier this year. Our server has been around a long time, and has a very strong cross-release capability. We had to accept both secure and non-secure connections, in particular where the client doesn't know how to negotiate a secure session. Release transition is really important to us, so we had to be able to accept both on the same port. I got good suggestions from other members on this list. visit here http://www.mail-archive.com/[EMAIL PROTECTED]/msg34924.html for a useful reply to my original question. I got several off-list replies, which I'll search for if needed. For more details my own user experience, we can take the details off-list. Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frédéric PAILLETTE Sent: Wednesday, September 29, 2004 4:47 AM To: [EMAIL PROTECTED] Subject: Secure and non secure connection Hi all ! I must secure a daemon with openssl. I would like to be able to accept secure and non secure connections on the same port. Someone has also done something like that ? TIA Frédéric __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL 0.9.7d WIN - IA64 port
Hi Richard. thanks for your reply. In my experiments so far, I have seen the messages about size_t and unsigned long. This is the one that worried me some. How can I watch for news about this work? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Levitte - VMS Whacker Sent: Tuesday, August 17, 2004 4:04 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL 0.9.7d WIN - IA64 port In message [EMAIL PROTECTED] mcast.net on Mon, 16 Aug 2004 17:41:29 +, [EMAIL PROTECTED] said: d.mclellan Hi: I'm now investigating build OpenSSL -0.9.7d on a WIN d.mclellan IA64 architecture machine. Has anyone had any experience d.mclellan with this, or is there any active work in progress to d.mclellan support WIN IA64 platforms? d.mclellan Thanks very much. The absolutely biggest problem is that size_t is 64 bits while unsigned long is 32 bits. This leads to a ton of warnings/errors concerning size differences when OpenSSL uses unsigned long, unsigned int or int for things that should really be size_t. There's a branch where work on this is done, although very slowly (at least for the moment). If I didn't have to spend time chasing down finances to survive, that would be one of those things I'd work on, as it also concerns a favorite O/S of mine, VMS. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: How should I start?
Hi Layla:A few months ago, I was in the same position as you are now, and have just turned over my first such effort to my QA group. This list is a great resource and I've learned a lot by watching it. Many experienced implementors and the developers watch and reply on this list. visit: www.openssl.org/docsand follow the four links (crypto, ssl, openssl, howto). The O'Reilly book is excellent, and so is Eric Rescorla's book SSL and TLS - Designing and Building Secure Systems. Dave -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of LaylaSent: Sunday, August 15, 2004 4:22 AMTo: [EMAIL PROTECTED]Subject: How should I start? Hello Everyone: I'm supposed to implement a security protocol using OpenSSL (C++) on windows platform. My qusetion is how can I get myself familiar with using the functions offered by OpenSSL. can anyone please recommend a reference or perhaps a website. I've already ordered this book: Network Security with OpenSSL But i would really appreciate it if anyone can tell me where to start from, or if there's even some sort of a catalog listing the different functions and their uses. Thank you all in advance. Layla. Do you Yahoo!?Yahoo! Mail - Helps protect you from nasty viruses.
Fork() after a good SSL_connect and SSL_accept - does it work?
Title: Fork() after a good SSL_connect and SSL_accept - does it work?
I have a closed ('closed' in the sense that produce the client and the server applications) client/server application which optionally uses SSL to secure the session. It's a mature propretiary client/server protocol which has been enhanced to add the SSL support.
On most platforms, the server starts a new thread to handle a new connection, but this happens after we execute the connect/accept sequence. That is, the listener thread accepts and SSL_accepts the client, and then starts a new thread to handle the client.
On a couple of platforms, we can't, because of unrelated architectural reasons, use a thread for a new session. We have to fork a new process after the accepting the client. Is there any prayer for the child process, with inherited socket and memory image of the SSL structures, to actually succeed? Do I need to re-initialize the library and everything else in the child process? What the heck else would I have to do in this architecture.
Does anyone have experience with SSL in forked environments? Thanks for your advice. I have seen some hits on fork behavior in the archives but no answers.
Dave McLellan --Consulting Software Engineer - SPEA Engineering
EMC Corporation
228 South St. Mail Stop: 228 LL/AA-24
Hopkinton, MA 01748 USA
+1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED]
NEWBIE: The man pages in a PDF file
Title: NEWBIE: The man pages in a PDF file Sorry, this is a really naïve question. I'm really getting a lot out of the man pages once I figured out how to dig through it. But it's time-consuming to pick and choose the sections to print. Does anyone know whether there a PDF version of the man pages somewhere in the world? Individual sections? Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED]
