Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH
Hi, Thank you for the clarifications. Regards, Sanjaya On Fri, Jun 8, 2018 at 4:30 PM, Jakob Bohm wrote: > (Top posting for consistency). > > Once the client receives the TLS1.2 servers choice of DH group, > it can either accept it or abort the connection. > > However if both client and server support the "supported_groups" > extension (RFC4492) with the additional DH group identifiers in > RFC7919, they can negotiate a common accepted group of desired > strength, though the mechanism (like TLS1.3) is artificially > limited to a fixed set of groups listed in the RFC. > > > On 08/06/2018 12:15, Sanjaya Joshi wrote: > >> Hello, >> Thank you Matt and Jordan. So, it seems that it's possible to modify my >> client to accept/reject the DH group key length. But i have one more issue >> to be clarified. >> >> Is it possible that if a client does not accept the DH group key length >> used by the server, then, a different possible cipher (for e.g., RSA) is >> tried to be negotiated. It seems that the connection is rejected, instead >> of falling back to a different possible cipher. At least, i tested this >> quickly using s_client and s_server, and the behavior is as stated above, >> i.e., no fallback and connection was terminated. Is this the default >> OpenSSL behavior or this behaviour could be modified somehow by >> applications ? >> >> Regards, >> Sanjaya >> >> On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell > m...@openssl.org>> wrote: >> >> >> >> On 07/06/18 16:02, Jordan Brown wrote: >> > I do not understand, however, how the 80 relates to a 1024-bit >> limit. >> >> It's a measure of the "security bits" of an algorithm according to >> table >> 2 in this doc: >> https://nvlpubs.nist.gov/nistpubs/specialpublications/nist. >> sp.800-57pt1r4.pdf >> <https://nvlpubs.nist.gov/nistpubs/specialpublications/nist. >> sp.800-57pt1r4.pdf> >> >> > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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-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] Selection of DHE ciphers based on modulus size of DH
Hello, Thank you Matt and Jordan. So, it seems that it's possible to modify my client to accept/reject the DH group key length. But i have one more issue to be clarified. Is it possible that if a client does not accept the DH group key length used by the server, then, a different possible cipher (for e.g., RSA) is tried to be negotiated. It seems that the connection is rejected, instead of falling back to a different possible cipher. At least, i tested this quickly using s_client and s_server, and the behavior is as stated above, i.e., no fallback and connection was terminated. Is this the default OpenSSL behavior or this behaviour could be modified somehow by applications ? Regards, Sanjaya On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell wrote: > > > On 07/06/18 16:02, Jordan Brown wrote: > > I do not understand, however, how the 80 relates to a 1024-bit limit. > > It's a measure of the "security bits" of an algorithm according to table > 2 in this doc: > https://nvlpubs.nist.gov/nistpubs/specialpublications/ > nist.sp.800-57pt1r4.pdf > > Matt > -- > 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] Selection of DHE ciphers based on modulus size of DH
Hello, Thank you all for your responses. I forgot to mention that we are on OpenSSL 1.1.0 and TLS 1.2. I have some more queries though. >>Current OpenSSL isn't willing to connect to a server using a DH key size below 1024 bits. Yes, i have verified this. However, not sure, how my OpenSSL-based client can do this, as our requirement is that we must not use DH key size below 2048 bits. >> I'm pretty sure that clients can and do refuse to talk to servers with small DH parameters. Could you please provide some more clues how a client can do so ? >> However, in TLS 1.3, the FFDHE groups are pre-defined, and the server >>does not get to choose ad-hoc (p, g) pairs Yep; i saw them. Here, client plays a role to offer the supported DHE first and then, the server can use that - just like elliptic curve negotiation. But again, one catch is that custom DH groups are no more allowed, for which i didn't find a good reasoning. Regards, Sanjaya On Thu, Jun 7, 2018 at 8:52 AM, Jordan Brown wrote: > On 6/6/2018 12:11 PM, Sanjaya Joshi wrote: > > I understood that when DHE ciphers are tried to be used between two > entities, it's only the server that plays a role about selection of the DH > parameters. This is not negotiable with the client. For e.g., the server > can freely use a very low not-recommended DH group with 512 bit key length > and the client cannot deny it. > > > I'm pretty sure that clients can and do refuse to talk to servers with > small DH parameters. > > Current OpenSSL isn't willing to connect to a server using a DH key size > below 1024 bits. > > https://www.openssl.org/blog/blog/2015/05/20/logjam-freak- > upcoming-changes/ > > To protect OpenSSL-based clients, we’re increasing the minimum accepted DH > key size to 768 bits immediately in the next release, and to 1024 bits soon > after. > > > -- > Jordan Brown, Oracle Solaris > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Selection of DHE ciphers based on modulus size of DH
Hello, I understood that when DHE ciphers are tried to be used between two entities, it's only the server that plays a role about selection of the DH parameters. This is not negotiable with the client. For e.g., the server can freely use a very low not-recommended DH group with 512 bit key length and the client cannot deny it. Is this understanding still correct or this has been changed recently ? Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Binding the socket to a source IP address before connect
Hi, Thanks Michael. I'll check if your proposal fits my requirement. Regards, Sanjaya On Wed, Jan 10, 2018 at 7:55 PM, Michael Richardson <m...@sandelman.ca> wrote: > > Sanjaya Joshi <joshi.sanj...@gmail.com> wrote: > > Is there a BIO family of API that OpenSSL provides to bind to a > > specific source IP address before creating a socket connection (using > > for e.g. BIO_new_connect()) ? > > I think not... BIO_new_connect() allocates the BIO, and so there isn't any > state to set up before you call that. > > I've had to add a place to store the sockaddr to the DGRAM method in order > to > make DTLS work the way I want it, and it could be extended to TCP sockets I > think, but not using the flow that you are using. > > However, you can provide the FD to the SSL context using BIO_set_fd() > and SSL_set_bio(): > > BIO_set_fd(inbio, connectedfd, BIO_NOCLOSE); > SSL_set_bio(ssl, inbio, outbio); > > Then you can set up the connectedfd any way you want, calling bind() before > connect. That means that you might have to parse the host/IP + port > yourself, but getaddrinfo() can do that for you, and > int BIO_lookup(const char *host, const char *service, > enum BIO_lookup_type lookup_type, > int family, int socktype, BIO_ADDRINFO **res); > > wraps it all nicely for you. > > > My application does not need to rely on the kernel-provided source IP > > address and hence the need for this. > > Just remember to test with IPv6 Link-Local addresses, because they do > matter, and they are hard to get right from userspace. > (And if you aren't doing IPv6 testing, then you probably shouldn't be > creating new code) > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on > rails[ > > > -- > 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
[openssl-users] Binding the socket to a source IP address before connect
Hello, Is there a BIO family of API that OpenSSL provides to bind to a specific source IP address before creating a socket connection (using for e.g. BIO_new_connect()) ? My application does not need to rely on the kernel-provided source IP address and hence the need for this. Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Compatibility between different openssl versions
Hi, Thank you Salz Rich. It's clear now. Regards, Sanjaya On Mon, Nov 27, 2017 at 6:42 PM, Salz, Rich via openssl-users < openssl-users@openssl.org> wrote: > >- Whether openssl 1.0.x and 1.1.x can interwork ? > > > > Yup. As long as they share a TLS version, no problem. > > -- > 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] Compatibility between different openssl versions
Thank you for the confirmation Matt. Regards, Sanjaya On Mon, Nov 27, 2017 at 3:50 PM, Matt Caswell <m...@openssl.org> wrote: > > > On 27/11/17 08:47, Sanjaya Joshi wrote: > > Hello, > > Whether openssl 1.0.x and 1.1.x can interwork ? > > That is, whether TLS client on top of openssl 1.1.x and TLS server on > > top of openssl 1.0.x (or vice versa) can interwork efficiently ? > > Yes - absolutely. > > Matt > > -- > 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
[openssl-users] Compatibility between different openssl versions
Hello, Whether openssl 1.0.x and 1.1.x can interwork ? That is, whether TLS client on top of openssl 1.1.x and TLS server on top of openssl 1.0.x (or vice versa) can interwork efficiently ? Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Segmentation fault ssl23_connect()
Thanks. I'll try that. Regards, Sanjaya On 18 Apr 2017 15:27, "Matt Caswell" <m...@openssl.org> wrote: > > > On 16/04/17 20:17, Sanjaya Joshi wrote: > > Hello, > > > > I use openldap_2.3.39 to initiate secure LDAP connection (starttls) to > > external LDAP server. The used openssl version is 1.0.2k. > > > > While establishing the secure connection from client, i observe the > > following segmentation fault occasionally (Not always reproducible). > > > > Any pointers please ? > > > > Are you able to compile openssl with debug symbols? That's not a lot to > go on. > > Matt > > > " > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib64/libthread_db.so.1". > > Core was generated by `/opt/nsn/pac_bor_qx_e1/bin/border'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > > (gdb) bt > > #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > > #1 0x7fd6b3495516 in ssl23_connect () from > /usr/lib64/libssl.so.1.0.0 > > #2 0x7fd6b7d2d6cf in ldap_int_tls_connect (ld=0x7fd6880486d0, > > conn=0x7fd68802d9e0) at tls.c:805 > > #3 0x7fd6b7d2ece0 in ldap_int_tls_start (ld=0x7fd6880486d0, > > conn=0x7fd68802d9e0, srv=0x0) at tls.c:1511 > > #4 0x7fd6b7d2f6e9 in ldap_install_tls (ld=0x7fd6880486d0) at > tls.c:1935 > > #5 0x7fd6bb46c6c1 in open_connection_as > > (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, > client_access=0, > > user_dn=0x7fd6880543c8 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, > > network_timeout=5000, request_id=0x7fd6962d144c, > > error_string=0x7fd6962d1440, isSecure=2, cacertFile=0x7fd688048bf8 > > "/etc/certs/cacert.pem", > > ciphers=0x7fd68805e138 > > "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", > > reqCert=0x7fd6962d2558) at ../src/api.c:1048 > > #6 0x7fd6bb46ca97 in open_secure_connection_starttls_request > > (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, > > client_access=0, user_dn=0x7fd6880543c8 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, > > network_timeout=5000, request_id=0x7fd6962d144c, > > error_string=0x7fd6962d1440, cacertFile=0x7fd688048bf8 > > "/etc/certs/cacert.pem", > > ciphers=0x7fd68805e138 > > "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", > > reqCert=0x7fd6962d2558) at ../src/api.c:1258 > > #7 0x7fd6b9c899c8 in tryConnectExtLdap (host=0x7fd68805de90 > > "10.55.433.1", port=389, > > binddn=0x7fd6962d3380 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > pwd=0x7fd6962d3c70 "saaadh45sks", > > _extHandle=@0x7fd6962d2838: 0x7fd6880486d0, peopledn=0x7fd6880495b0 > > "ou=people,ou=accounts,dc=sasa,dc=test,dc=net", secureMode=0, > > cacertFile=..., ciphers=..., reqCert=5, timeout_ms=5000) > > at ../../src/acct.cpp:1694 > > #8 0x7fd6b9c88df1 in validate_account (accountName=0x7fd6962d3380 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > accountPassword=0x7fd6962d3c70 "saaadh45sks") at > ../../src/acct.cpp:1623 > > #9 0x00479d3a in set_acc > > (userName=userName@entry=0x7fd6962d3870 "user1", > > password=password@entry=0x7fd6962d3c70 "saaadh45sks") at > > ../src/borfunc_cou.c:4066 > > #10 0x0045217b in _71571_2 (_T=0x42907000) at > > ../src/bor7qxqx.sdl:600 > > #11 0x0044fd45 in _s71571_ACTIVE (_T=) at > > _Sborha7ACTIVE.c:33 > > #12 0x7fd6b6ec8a65 in call_transition (msg=0x7fd6bc0d8948, > process=96) > > at /home/core/threadmain.c:656 > > #13 call_transition_with_fatal_sig_catching (thread=, > > thread@entry=0x25d7d90, process=process@entry=96, > > msg=msg@entry=0x7fd6bc0d8948) at /home/core/threadmain.c:669 > > #14 0x7fd6b6ec9499 in execute_user_code (msg=0x7fd6bc0d8948, > > process=96, thread=0x25d7d90) > > at /home/core/threadmain.c:687 > > #15 exec_main_loop (thread=0x25d7d90) at /home/core/threadmain.c:882 > > #16 thread_context_main (arg=) at > /home/core/threadmain.c:592 > > #17 0x7fd6b64f2f50 in ?? () from /lib64/libc.so.6 > > #18 0x in ?? () > > (gdb) > > " > > > > Regards, > > Sanjaya > > > > > -- > 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
[openssl-users] Segmentation fault ssl23_connect()
Hello, I use openldap_2.3.39 to initiate secure LDAP connection (starttls) to external LDAP server. The used openssl version is 1.0.2k. While establishing the secure connection from client, i observe the following segmentation fault occasionally (Not always reproducible). Any pointers please ? " [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/opt/nsn/pac_bor_qx_e1/bin/border'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 (gdb) bt #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 #1 0x7fd6b3495516 in ssl23_connect () from /usr/lib64/libssl.so.1.0.0 #2 0x7fd6b7d2d6cf in ldap_int_tls_connect (ld=0x7fd6880486d0, conn=0x7fd68802d9e0) at tls.c:805 #3 0x7fd6b7d2ece0 in ldap_int_tls_start (ld=0x7fd6880486d0, conn=0x7fd68802d9e0, srv=0x0) at tls.c:1511 #4 0x7fd6b7d2f6e9 in ldap_install_tls (ld=0x7fd6880486d0) at tls.c:1935 #5 0x7fd6bb46c6c1 in open_connection_as (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, client_access=0, user_dn=0x7fd6880543c8 "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, network_timeout=5000, request_id=0x7fd6962d144c, error_string=0x7fd6962d1440, isSecure=2, cacertFile=0x7fd688048bf8 "/etc/certs/cacert.pem", ciphers=0x7fd68805e138 "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", reqCert=0x7fd6962d2558) at ../src/api.c:1048 #6 0x7fd6bb46ca97 in open_secure_connection_starttls_request (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, client_access=0, user_dn=0x7fd6880543c8 "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, network_timeout=5000, request_id=0x7fd6962d144c, error_string=0x7fd6962d1440, cacertFile=0x7fd688048bf8 "/etc/certs/cacert.pem", ciphers=0x7fd68805e138 "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", reqCert=0x7fd6962d2558) at ../src/api.c:1258 #7 0x7fd6b9c899c8 in tryConnectExtLdap (host=0x7fd68805de90 "10.55.433.1", port=389, binddn=0x7fd6962d3380 "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", pwd=0x7fd6962d3c70 "saaadh45sks", _extHandle=@0x7fd6962d2838: 0x7fd6880486d0, peopledn=0x7fd6880495b0 "ou=people,ou=accounts,dc=sasa,dc=test,dc=net", secureMode=0, cacertFile=..., ciphers=..., reqCert=5, timeout_ms=5000) at ../../src/acct.cpp:1694 #8 0x7fd6b9c88df1 in validate_account (accountName=0x7fd6962d3380 "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", accountPassword=0x7fd6962d3c70 "saaadh45sks") at ../../src/acct.cpp:1623 #9 0x00479d3a in set_acc (userName=userName@entry=0x7fd6962d3870 "user1", password=password@entry=0x7fd6962d3c70 "saaadh45sks") at ../src/borfunc_cou.c:4066 #10 0x0045217b in _71571_2 (_T=0x42907000) at ../src/bor7qxqx.sdl:600 #11 0x0044fd45 in _s71571_ACTIVE (_T=) at _Sborha7ACTIVE.c:33 #12 0x7fd6b6ec8a65 in call_transition (msg=0x7fd6bc0d8948, process=96) at /home/core/threadmain.c:656 #13 call_transition_with_fatal_sig_catching (thread=, thread@entry=0x25d7d90, process=process@entry=96, msg=msg@entry=0x7fd6bc0d8948) at /home/core/threadmain.c:669 #14 0x7fd6b6ec9499 in execute_user_code (msg=0x7fd6bc0d8948, process=96, thread=0x25d7d90) at /home/core/threadmain.c:687 #15 exec_main_loop (thread=0x25d7d90) at /home/core/threadmain.c:882 #16 thread_context_main (arg=) at /home/core/threadmain.c:592 #17 0x7fd6b64f2f50 in ?? () from /lib64/libc.so.6 #18 0x in ?? () (gdb) " Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reg, TLS over SCTP (SOCK_SEQPACKET)
Hi, Thanks for the pointers. We will consider that option. Regards, Sanjaya On Wed, Mar 1, 2017 at 6:59 PM, Michael Tuexen < michael.tue...@lurchi.franken.de> wrote: > > On 1 Mar 2017, at 06:34, Sanjaya Joshi <joshi.sanj...@gmail.com> wrote: > > > > Hi, > > Thank you Salz Rich for the confirmation. > > So, whether application can perform manual TLS handshakes when > SOCK_SEQPACKET is used ? > I this the SOCK_SEQPACKET model doesn't fit well to the way the openssl > code is layed out. > They basically want a one-to-one relation between a bio (for example a > socket bio) and > a TLS connection. So there is no muxing/demuxing ongoing. > > I'm wondering why you are sticking to the 1-to-many style sockets and why > you are not > considering DTLS over SCTP instead of TLS over SCTP. DTLS over SCTP using > one-to-one > style sockets (SOCK_STREAM) is supported by OpenSSL on Linux and FreeBSD. > > Best regards > Michael > > > > Regards, > > Sanjaya > > > > On Tue, Feb 28, 2017 at 7:03 PM, Salz, Rich <rs...@akamai.com> wrote: > > > But these calls don't work when SOCK_SEQPACKET (one-to-many > connections) is used. Does openssl provide any alternatives for these calls > ? Or an application need to perform the TLS handshakes manually ? > > > > This is not supported, and there are no demo's available. > > -- > > 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 > > -- > 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] Reg, TLS over SCTP (SOCK_SEQPACKET)
Hi, Thank you Salz Rich for the confirmation. So, whether application can perform manual TLS handshakes when SOCK_SEQPACKET is used ? Regards, Sanjaya On Tue, Feb 28, 2017 at 7:03 PM, Salz, Richwrote: > > But these calls don't work when SOCK_SEQPACKET (one-to-many connections) > is used. Does openssl provide any alternatives for these calls ? Or an > application need to perform the TLS handshakes manually ? > > This is not supported, and there are no demo's available. > -- > 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
[openssl-users] Reg, TLS over SCTP (SOCK_SEQPACKET)
Hello, I understand that when implementing TLS over SCTP, if socket is opened with SOCK_STREAM (one-to-one connection), then normal openssl calls (SSL_accept, SSL_connect) can be used for TLS handshakes in a client/server program. But these calls don't work when SOCK_SEQPACKET (one-to-many connections) is used. Does openssl provide any alternatives for these calls ? Or an application need to perform the TLS handshakes manually ? Also, whether openssl has any sample program for TLS over SCTP with SOCK_SEQPACKET ? Would appreciate a quick reply. Thanks in advance. Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Clarification regarding CVE-2016-2178 for openssl 1.0.2 i and 1.0.2 j
Hello, 1) In openssl1.0.2i, the release note says, there is a fix for CVE-2016-2178: " *) Constant time flag not preserved in DSA signing Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. This has been demonstrated through a cache-timing attack to be sufficient for an attacker to recover the private DSA key. This issue was reported by César Pereida (Aalto University), Billy Brumley (Tampere University of Technology), and Yuval Yarom (The University of Adelaide and NICTA). (CVE-2016-2178) [César Pereida] " 2) And the related code diff in git is: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=399944622df7bd81af62e67ea967c470534090e2 3) But when i download the source code (1.0.2i and 1.0.2j), i cannot see those fixes. Could you please clarify a bit about this. Is this intended or i just need to apply the patches myself ? Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Reg. SHA512WithRSAEncryption support in TLSv1.0
Hello, I use a server certificate that is signed by the CA with SHA512WithRSAEncryption as the signature-algorithm. During the TLS communication, my client is not able to verify the server certificate, and in the wireshark trace, i can see the error "Decrypt Error". Does it mean that my client does not support SHA512 ? I use TLSv1.0. Could someone please let me know, if SHA512 is not supported by TLSv1.0 ? Thanks in advance. Regards, Sanjaya Joshi ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Reg. type of certificate - CA / EE based on X509_check_ca().
Thanks for the reply Tom and Kyle H. Now i have below 2 questions: (1) Based on application's need, can we assume return codes 2, 3 and 4 as non-CA ? (2) If we get return code 4 basicConstraints absent but keyUsage present and keyCertSign asserted for a certificate, is this a valid certificate ? Because RFC 3280 says: The keyCertSign bit is asserted when the subject public key is used for verifying a signature on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (section 4.2.1.10) MUST also be asserted. Regards, Sanjaya On Tue, Jul 8, 2014 at 2:16 AM, Kyle Hamilton aerow...@gmail.com wrote: On 7/7/2014 2:40 AM, Sanjaya Joshi wrote: Hello, My application uses openssl 1.0.0, and it uses X509_check_ca() to find out if an X509 certificate is a CA certificate, or an End-entity (EE) certificate. The below are the possible return codes. /* return codes of X509_check_ca(): * 0 not a CA * 1 is a CA * 2 basicConstraints absent so maybe a CA * 3 basicConstraints absent but self signed V1. * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. */ My question here is, if we get return code as 4, should we consider this as a CA certificate or an EE certificate ? Any quick support in this regard is much appreciated. Regards, Sanjaya This depends on your environment, and the types of certificates that the CAs used issue. The reason the codes are differentiated is because the authors of the library can't make a blanket determination for the library's clients. :P -Kyle H
Reg. type of certificate - CA / EE based on X509_check_ca().
Hello, My application uses openssl 1.0.0, and it uses X509_check_ca() to find out if an X509 certificate is a CA certificate, or an End-entity (EE) certificate. The below are the possible return codes. /* return codes of X509_check_ca(): * 0 not a CA * 1 is a CA * 2 basicConstraints absent so maybe a CA * 3 basicConstraints absent but self signed V1. * 4 basicConstraints absent but keyUsage present and keyCertSign asserted. */ My question here is, if we get return code as 4, should we consider this as a CA certificate or an EE certificate ? Any quick support in this regard is much appreciated. Regards, Sanjaya
Re: PKCS#1 key vs PKCS#8...
Hi Steve, Thanks for the reply. Yes it should have been handled, but i am not sure about the strongswan implementation. Anyways, it's mentioned in their release notes that pkcs8 is supported v_4.6.* onwards. I have another question. 1. I use openssl 1.0.0, and i use RSA_generate_key_ex() to create RSA key. After that, i use PEM_write_PrivateKey() to write it to a file, and use further. By doing this, the written key is a PKCS#8 encoded key. Which API should be used instead of PEM_write_PrivateKey(), if i want a PKCS#1 encoded traditional key ? Is it OK to use PEM_write_RSAPrivateKey() to get PKCS#1 encoded key in openssl 1.0.0 ? Note: In openssl 0.9.8, PEM_write_PrivateKey() provides a PKCS#1 encoded key. Regards, Sanjaya On Wed, Jun 5, 2013 at 6:33 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Tue, Jun 04, 2013, sanjaya joshi wrote: Hello, I am using strongswan(v_4.5.3) for ipsec, that uses my X509 certificate and RSA private key. If i use RSA private key(un-encrypted) that is PKCS#8 encoded, then strongswan is not able to load the key. But it works, if i use a traditional PKCS#1 encoded RSA key. That's strange. If it uses the standard PEM routines to read in a private key OpenSSL should transparently handle PCKS#8 format. 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
Re: Change in behavior of api PEM_write_PrivateKey() between 0.9.8 and 1.0.0
Thanks Dave for the clarifications. Regards, Sanjaya On Thu, Jun 6, 2013 at 2:11 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of sanjaya joshi Sent: Wednesday, 05 June, 2013 01:27 I have few queries wrt the RSA private key generation and writing using openssl. Could anybody please clearify. (1). Has the behavior of api PEM_write_PrivateKey() has been changed between openssl 0.9.8 and 1.0.0 ? (2). The above api uses PKCS#8 encoding (while writing) by default in 1.0.0, but uses PKCS#1 in 0.9.8. Is this correct ? Yes. More exactly, since 0.9.8 there have been and still are: - PEM_write[_bio]_x routines for algorithm-specific forms (RSAPrivateKey, DSAPrivateKey, ECPrivateKey); for RSA this is PKCS#1 - routine(s) for PKCS8PrivateKey which does PKCS#8 There is also a generic routine PrivateKey which in 0.9.8 dispatched to the algorithm-specific routines but =1.0.0 just uses PKCS#8. Note the PEM_read_ routines (all, I think) accept either form, distinguished by tag in the BEGIN line. This explains the difference you note elsethread in commandline pkcs8. pkcs8 'import' (not -topk8, outformat PEM) uses PEM_write_PrivateKey. (3). But while generating RSA key using openssl command, no change in the behavior, in both the versions. Is this correct ? Commandline genrsa uses write_bio_RSAPrivateKey which is PKCS#1. genpkey for any supported algorithm including RSA writes PKCS#8. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PKCS#1 key vs PKCS#8...
Hello, I am using strongswan(v_4.5.3) for ipsec, that uses my X509 certificate and RSA private key. If i use RSA private key(un-encrypted) that is PKCS#8 encoded, then strongswan is not able to load the key. But it works, if i use a traditional PKCS#1 encoded RSA key. Could anyone explain, which one is a better recommendation (PKCS#1 or PKCS#8) ? Regards, Sanjaya
Convertion of pkcs8 to pkcs1 key...
Hello, Could anyone let me know which is the suitable openssl command to convert PKCS#8 key to traditional PKCS#1 key in openssl_1.0.0? I used the below command, and it works in openssl_1.0.0:- openssl rsa -in pkcs8.pem -out pkcs1.pem But if i use the below command, it doesn't work in openssl_1.0.0 (whereas it works in openssl_0.9.8):- openssl pkcs8 -nocrypt -in pkcs8.pem -out pkcs1.pem Regards, Sanjaya
Change in behavior of api PEM_write_PrivateKey() between 0.9.8 and 1.0.0
Hello, I have few queries wrt the RSA private key generation and writing using openssl. Could anybody please clearify. (1). Has the behavior of api PEM_write_PrivateKey() has been changed between openssl 0.9.8 and 1.0.0 ? (2). The above api uses PKCS#8 encoding (while writing) by default in 1.0.0, but uses PKCS#1 in 0.9.8. Is this correct ? (3). But while generating RSA key using openssl command, no change in the behavior, in both the versions. Is this correct ? Regards, Sanjaya
CMP key update - Which key to be used?
Hello, I need to update my end entity certificate using CMP key update request. There are 2 possibilities for the private key to be used - 'existing' or 'new'. RFC 4210 says: When a key pair is due to expire, the relevant end entity MAY request a key update; that is, it MAY request that the CA issue a new certificate for a new key pair (or, in certain circumstances, a new certificate for the same key pair). . Q1. Is there any valid use case, where i need a new certificate for the same(existing) key pair ? Or, is it ok, if i mandate my application to always use a new key pair ? Q2. In case of end entity certificate update/rekey, is there any policy available for the CA to revoke the old end entity certificate, after issuing a new certificate ? [provided the old end entity certificate is not yet expired] Appreciate an early reply. Regards, Sanjaya
Re: X509 V1 intermediate CA vs end-entity
Hi steve, Thanks. Got it. That means we can't differentiate between CA and end-entity in case of V1 certificate. We can only find out if the V1 cert is a self-signed certificate or not. Correct ? Regards, Sanjaya On Wed, Sep 26, 2012 at 2:36 AM, Dr. Stephen Henson st...@openssl.orgwrote: On Tue, Sep 25, 2012, sanjaya joshi wrote: We can conclude an X509 V1 certificate to be a root ca using (EXFLAG_V1|EXFLAG_SS). Similarly, is there a way to know whether an X509 V1 certificate is an intermediate CA or end-entity certificate ? You can't: there is nothing in a V1 certificate to mark it as a CA. You can't actually be sure it is a root CA using the test you mentioned above: it could be a self signed end entity certificate. 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