Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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()

[Sanjaya Joshi]

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()

[Sanjaya Joshi]

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)

[Sanjaya Joshi]

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)

[Sanjaya Joshi]

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, Rich  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] Reg, TLS over SCTP (SOCK_SEQPACKET)

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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

[Sanjaya Joshi]

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().

[Sanjaya Joshi]

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().

[Sanjaya Joshi]

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...

[sanjaya joshi]

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

[sanjaya joshi]

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...

[sanjaya joshi]

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...

[sanjaya joshi]

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

[sanjaya joshi]

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?

[sanjaya joshi]

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

[sanjaya joshi]

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