Re: OpenSSL and DH parameters
On 10/24/13 1:59 PM, Dave Thompson wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html It suggests that if the client offers P-256 and P-384, but the server's tmp_ecdh is set to P-521, then the server will pick an elliptic curve cipher suite anyway, try to force P-521 on the client, and the handshake will fail. Hence his assertion With TLS, no EC is better than crippled EC. This seems very wrong to me! If the client and server can't agree on a curve, shouldn't the server just pick a non-elliptic-curve cipher suite that both it and the client support instead? It seems like offering EC should never be worse than not offering EC! The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ Is this true? And why? It doesn't seem like it should work that way. --Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Calling FINGERPRINT_premain on more c++ compiler/platforms
I am trying to use a statically link OpenSSL in FIPS mode on IBM PLinux using
xlC_r as the compiler/linker. This combination is not supported by fipsld or
fips_premain.c. fipld will add linker options to call FINGERPRINT_premain on
uname -s in {OSF1, IRIX, HP-UX, AIX, Darwin}, fips_premain.c will do compiler
specific solutions for gcc, cl(Microsoft), cc(SUN), and some others that I am
not familiar with. Unfortunately xlC_r on IBM PLinux is not covered by either
of those so I would like to know if adding the following code to one of my cpp
files is acceptable for FIPS validation or if I need to change my
compiler/linker to gcc or is there another way(linker options?) to keep xlC_r.
Please include some justification.
#if defined(PREMAIN_NOT_COVERED)
extern C void FINGERPRINT_premain(void);
class FIPSInitializer
{
public:
FIPSInitializer()
{
FINGERPRINT_premain();
}
virtual ~FIPSInitializer()
{
}
};
extern FIPSInitializer fips_initializer;
FIPSInitializer fips_initializer;
#endif
I also tried using -Wl,init,FINGERPRINT_premain while linking, but then our
test would segfault while using our shared library.
-Ty
Re: Do SSL_shutdown() and SSL_get_error() mix?
On Thu, Oct 24, 2013 at 03:59:08PM -0400, Dave Thompson wrote: 0 The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error(3) may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. D'oh! How on earth did I miss that? Thanks. -- O Unicef Clearasil! Gibberish and Drivel! -- Bored of the Rings __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DTLS PSK in FIPS mode
Hi! I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)). If I do, I get crashes as below where p =0; Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffddffb700 (LWP 15278)] 0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at d1_pkt.c:680 680*p == SSL3_MT_CLIENT_HELLO) (gdb) bt #0 0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at d1_pkt.c:680 #1 0x7752ef7f in dtls1_read_bytes (s=0x7fffc8000c00, type=22, buf=0x7fffddffa990 \300\251\377\335\377\177, len=12, peek=0) at d1_pkt.c:838 #2 0x775327cd in dtls1_get_message_fragment (s=0x7fffc8000c00, st1=8465, stn=8466, max=16384, ok=0x7fffddffaa44) at d1_both.c:788 #3 0x77531699 in dtls1_get_message (s=0x7fffc8000c00, st1=8465, stn=8466, mt=1, max=16384, ok=0x7fffddffaa44) at d1_both.c:436 #4 0x77503a53 in ssl3_get_client_hello (s=0x7fffc8000c00) at s3_srvr.c:941 #5 0x7752712c in dtls1_accept (s=0x7fffc8000c00) at d1_srvr.c:298 #6 0x77536e85 in SSL_accept (s=0x7fffc8000c00) at ssl_lib.c:940 #7 0x7752dd38 in dtls1_listen (s=0x7fffc8000c00, client=0x7fffddffacf0) at d1_lib.c:477 #8 0x7752d715 in dtls1_ctrl (s=0x7fffc8000c00, cmd=75, larg=0, parg=0x7fffddffacf0) at d1_lib.c:263 #9 0x77537422 in SSL_ctrl (s=0x7fffc8000c00, cmd=75, larg=0, parg=0x7fffddffacf0) at ssl_lib.c:1106 #10 0x009b64a9 in (anonymous namespace)::listenThread (serverAddr=...) at /home/frja/srv_trunk/src/product/service/dtls/unix/dtlsserver.cpp:586 This is only a problem when combining PSK and FIPS, if I do either FIPS or PSK it works. Can anyone please help me out? Fredrik
Re: DTLS PSK in FIPS mode
Hi again,
in d1_pkt.c:574
(s-rstate != SSL_ST_READ_BODY) || (s-packet_length
DTLS1_RT_HEADER_LENGTH)) seems to be false at times. When the program
reaches *p == SSL3_MT_CLIENT_HELLO further down it fails (since p is
initialized to NULL).
if I add
if (NULL == p) {
p = s-packet;
}
before *p == SSL3_MT_CLIENT_HELLO, it works.
Should I report a bug?
Fredrik
On Fri, Oct 25, 2013 at 2:03 PM, Fredrik Jansson
fredrik.jansson...@gmail.com wrote:
Hi!
I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
If I do, I get crashes as below where p =0;
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffddffb700 (LWP 15278)]
0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at d1_pkt.c:680
680*p == SSL3_MT_CLIENT_HELLO)
(gdb) bt
#0 0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at
d1_pkt.c:680
#1 0x7752ef7f in dtls1_read_bytes (s=0x7fffc8000c00, type=22,
buf=0x7fffddffa990 \300\251\377\335\377\177, len=12, peek=0) at
d1_pkt.c:838
#2 0x775327cd in dtls1_get_message_fragment (s=0x7fffc8000c00,
st1=8465, stn=8466, max=16384, ok=0x7fffddffaa44) at d1_both.c:788
#3 0x77531699 in dtls1_get_message (s=0x7fffc8000c00, st1=8465,
stn=8466, mt=1, max=16384, ok=0x7fffddffaa44) at d1_both.c:436
#4 0x77503a53 in ssl3_get_client_hello (s=0x7fffc8000c00) at
s3_srvr.c:941
#5 0x7752712c in dtls1_accept (s=0x7fffc8000c00) at d1_srvr.c:298
#6 0x77536e85 in SSL_accept (s=0x7fffc8000c00) at ssl_lib.c:940
#7 0x7752dd38 in dtls1_listen (s=0x7fffc8000c00,
client=0x7fffddffacf0) at d1_lib.c:477
#8 0x7752d715 in dtls1_ctrl (s=0x7fffc8000c00, cmd=75, larg=0,
parg=0x7fffddffacf0) at d1_lib.c:263
#9 0x77537422 in SSL_ctrl (s=0x7fffc8000c00, cmd=75, larg=0,
parg=0x7fffddffacf0) at ssl_lib.c:1106
#10 0x009b64a9 in (anonymous namespace)::listenThread
(serverAddr=...) at
/home/frja/srv_trunk/src/product/service/dtls/unix/dtlsserver.cpp:586
This is only a problem when combining PSK and FIPS, if I do either FIPS or
PSK it works.
Can anyone please help me out?
Fredrik
Re: OpenSSL and DH parameters
On Thu, Oct 24, 2013 at 11:52:36PM -0700, Patrick Pelletier wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html With respect to the OpenSSL server implementation I was wrong. The issue was a bug in the RedHat OpenSSL package's recently introduced EC support advertising curves it did not implement. The issue is still possible if clients both send SSLv2 compatible HELLO (thus no extensions) and include EC ciphersuites. Since SSLv2 is now disabled by default, one might say they should not do that. The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ That's a deeper set of issues, that are still relevant. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
Hi, I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. If my understanding is correct, the DH parameters are used for key exchange also. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negociation will fail ? Thank you! On Friday, October 25, 2013 4:03 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Oct 24, 2013 at 11:52:36PM -0700, Patrick Pelletier wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html With respect to the OpenSSL server implementation I was wrong. The issue was a bug in the RedHat OpenSSL package's recently introduced EC support advertising curves it did not implement. The issue is still possible if clients both send SSLv2 compatible HELLO (thus no extensions) and include EC ciphersuites. Since SSLv2 is now disabled by default, one might say they should not do that. The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ That's a deeper set of issues, that are still relevant. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote: I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). No, this is optional. I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. No, this depends on the cipher-suite. If my understanding is correct, the DH parameters are used for key exchange also. No, not also, rather instead when an EDH cipher-suite is negotiated. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange.? When an EDH cipher-suite is negotiated. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negotiation will fail No, the server won't negotiate an EDH cipher-suite when it has no DH parameters. Clients don't begin EDH/EECDH key Exchange, servers do. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
Is it recommended to specify and use DH parameters for server ? I know that RSA encryption/decryption is slow and this is why RSA public keys are used only for establishing the session key which is a symmetric key usually because symetric key encryption is fast. If the negotiated cipher suite for an RSA encrypted client-server session does not involve using the RSA public keys, then when is RSA used in that session ? On Friday, October 25, 2013 4:49 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote: I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). No, this is optional. I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. No, this depends on the cipher-suite. If my understanding is correct, the DH parameters are used for key exchange also. No, not also, rather instead when an EDH cipher-suite is negotiated. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange.? When an EDH cipher-suite is negotiated. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negotiation will fail No, the server won't negotiate an EDH cipher-suite when it has no DH parameters. Clients don't begin EDH/EECDH key Exchange, servers do. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
DN attributes questions, and OpenSSL/GnuPG interoperability
I found the following using Google. ===begin quote=== IETF PKIX (latest version RFC 5280) is a well accepted profile for certificates. From section 4.1.2.4, the following fields must be supported (I've added between parenthesis is the OpenSSL long and optional short name): country (countryName, C), organization (organizationName, O), organizational unit (organizationalUnitName, OU), distinguished name qualifier (dnQualifier), state or province name (stateOrProvinceName, ST), common name (commonName, CN) and serial number (serialNumber). There's also a list of element that should be supported: locality (locality, L), title (title), surname (surName, SN), given name (givenName, GN), initials (initials), pseudonym (pseudonym) and generation qualifier (generationQualifier). =end quote=== But in Kleopatra, on OpenSuse 12.3, which I am trying to learn, I see in the DN-Attribute page, items like domain component (DC, I really don't know what this is), EMAIL, MAIL,MOBILE, PC, STREET, TEL, among others. However, when I use openssl to create a CSR, whether for a website or for a client side certificate, I am neveer prompted even for items like SN or GN, let alone STREET. Obviously, for a website, normally associated with a business, GN and SN aren't relevant, but items like STREET, PC, would be, and I am never prompted for those when trying to create a CSR for a website. And for client side certificates, I want the user's first and last names, mailing address, phone, c. in the certificates produced. How do I get tht information into the CSR/CRT files? I note that Kleopatra has a special section for GnuPG, but not one for OpenSSL. I know the two are note the same, but are they interoperable? That is, are GnuPG and OpenSSL client side certificates interchangable, in a single PKI system? Thanks Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL, Windows, Perl
Happy Linux OpenSSL user here. Moving to Windowsville. Haven't been there in over a decade. Read INSTALL.W32 and INSTALL.W64. Read Configure. Read crypto/asm/*.pl. Clearly Perl is needed to compile openssl with Visual Studio - which we will be using. Does OpenSSL need Perl at runtime? Thanks, Mike
RE: OpenSSL, Windows, Perl
Perl is simply used to configure the makefiles that build openssl. -Ike- John Eichenberger Principal Engineer: Sustaining Engineering: Intermec 425.265.2108 john.eichenber...@intermec.com From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Michael Mueller Sent: Friday, October 25, 2013 11:50 AM To: openssl-users@openssl.org Subject: OpenSSL, Windows, Perl Happy Linux OpenSSL user here. Moving to Windowsville. Haven't been there in over a decade. Read INSTALL.W32 and INSTALL.W64. Read Configure. Read crypto/asm/*.pl. Clearly Perl is needed to compile openssl with Visual Studio - which we will be using. Does OpenSSL need Perl at runtime? Thanks, Mike This message is intended only for the named recipient. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of this information is strictly prohibited.
