Re: [openssl-users] Rehandshake problem

[Ignacio Casal]

Hey,

this is on fedora 23, though I built openssl 1.0.1k (since it is the
version supported on rhel 6)
These are the specific test cases that are failing with openssl for us:
https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1948
https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1950

And here is where the second handshake happens:
https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n389

FWIW we are using our own bio:
https://git.gnome.org/browse/glib-networking/tree/tls/openssl/gtlsbio.c?h=wip/openssl

I can try to get you the pcap packet trace.

About " You would normally expect to get an SSL_ERROR_WANT_READ on the
client
side when the server sends the HelloRequest."

Yes this is what I would have expected as well.

Cheers.


On Fri, Nov 13, 2015 at 11:08 AM, Matt Caswell  wrote:

>
>
> On 13/11/15 08:37, Ignacio Casal wrote:
> > Hey guys,
> >
> > I am having a specific problem that I do not seem to find a solution for.
> >
> > - I have a server and a client that handshake properly
> > - the server will read from the client and the client from the server a
> > few bytes
> > - the client will try to read again
> > - the server will try to handshake again by calling SSL_renegotiate and
> > SSL_do_handshake. I get no errors in these calls.
> > - then I would expect the client to exit from the read call with an
> > error saying that needs to handshake again, instead it stays blocked on
> > the read until the server sends some data. But then I get an error
> > server side that there was no proper handshaking.
> >
> > Do you know how to get a notification client side that the client needs
> > to handshake again when blocked on a read or write?
>
> Which OpenSSL version/platform are you using? Can you get a pcap packet
> trace and post the specific errors that you are receiving?
>
> You would normally expect to get an SSL_ERROR_WANT_READ on the client
> side when the server sends the HelloRequest.
>
> Matt
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Ignacio Casal Quinteiro
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Rehandshake problem

[Ignacio Casal]

Hey guys,

I am having a specific problem that I do not seem to find a solution for.

- I have a server and a client that handshake properly
- the server will read from the client and the client from the server a few
bytes
- the client will try to read again
- the server will try to handshake again by calling SSL_renegotiate and
SSL_do_handshake. I get no errors in these calls.
- then I would expect the client to exit from the read call with an error
saying that needs to handshake again, instead it stays blocked on the read
until the server sends some data. But then I get an error server side that
there was no proper handshaking.

Do you know how to get a notification client side that the client needs to
handshake again when blocked on a read or write?

Cheers.

-- 
Ignacio Casal Quinteiro
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to get list of TLS protocols supported by OpenSSL?

[Matt Caswell]

On 13/11/15 02:56, pratyush parimal wrote:
> Hi,
> 
> I'm writing a client-server program that uses TLS for communication.
> I'm wondering if there's any way to programmatically find out which TLS
> protocol versions are supported by the OpenSSL library installed on my
> system.
> 
> I'm currently aware of three ways which "sort of" provide this information:
> (1) After setting up the TLS communication, call: SSL_get_version(ssl); 
> which returns "TLSV1.2", etc.
> (2) Try to connect to a server using TLS by specifying all possible TLS
> versions in the client program, and see which connections pass/fail.
> (3) Call: SSL_get_ciphers(), print their names, and try to correlate
> them with the protocol they're associated with.
> 
> Unfortunately, none of the above answer my question completely.
> 
> So is it possible to ascertain which TLS protocol versions are actually
> supported by my server-program, without trying the above methods? My
> purpose is not to simply make a list for my own reference, but rather
> finding it out on-the-fly in the server-side program, since I may run it
> on different versions of OpenSSL.

You can use the define TLS_MAX_VERSION to determine the highest protocol
version supported by the library.

If you also want to know the lowest version then that's a bit more
tricky. All current released versions will define OPENSSL_NO_SSL3 if
SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2
support has been compiled out (its not currently possible to compile out
other protocol versions). In the forthcoming 1.1.0 release SSLv2 support
has been completely removed so you don't get OPENSSL_NO_SSL2 even though
there is no SSLv2 support available (h...I wonder if we should add
that?). There are other SSLv2 defines in ssl2.h that are removed in
1.1.0 which you could use to detect whether you are on a version with
ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like
(completely untested):

#ifdef OPENSSL_NO_SSL3
#define TLS_MIN_VERSION TLS1_VERSION
#elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR)
#define TLS_MIN_VERSION SSL3_VERSION
#else
#define TLS_MIN_VERSION SSL2_VERSION
#endif

How future proof that is if we ever remove SSLv3 support I'm not sure.

Matt

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jakob Bohm]

On 13/11/2015 14:40, Emilia Käsper wrote:

Hi all,

We are considering removing from OpenSSL 1.1 known broken or outdated 
cryptographic primitives. As you may know the forks have already done 
this but I'd like to seek careful feedback for OpenSSL first to ensure 
we won't be breaking any major applications.


These algorithms are currently candidates for removal:

CAST
IDEA
MDC2
MD2 [ already disabled by default ]
RC5 [ already disabled by default ]
RIPEMD
SEED
WHIRLPOOL
ALL BINARY ELLIPTIC CURVES

My preference would be to remove these algorithms completely (as in, 
delete the code). Disabled-by-default code will either be re-enabled 
by distros (if there's widespread need for it - in which case we might 
as well leave it in) or will be poorly tested and is likely to just 
silently rot and break. This code is bloat and maintentance burden for 
us - my hope is that much of this code is effectively dead and can be 
removed.


*Are you aware of any mainstream need to continue supporting these 
algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or 
binary, or a standalone implementation or another crypto toolkit can 
always be used to continue supporting a legacy standalone application, 
or to decrypt ciphertext from the distant past. I am looking for use 
cases that could cause e.g. interop breakage between new and old 
peers, or major pain to distro end-users.


These algorithms are obsolete but removing them doesn't look feasible:

BLOWFISH - probably still in use though I don't know where exactly?
MD4 - used in NTLM
RC2 - used in PKCS#12

*Did I miss anything from the list?*


BlowFish is still hardcoded into some file formats that
are still in use, such as the PasswordSafe password
database format, I don't know if any related
implementations get the Blowfish code from OpenSSL
though.

IDEA was famously used in the original PGP encryption
format and as such remains useful when implementing
OpenPGP decryption on top of OpenSSL's libcrypto (as
opposed to implementing an OpenSSL emulation on top an
OpenPGP library like GNU did).  I don't know if any of
the 'OpenPGP in a high level language such as
perl/python/php' implementations use OpenSSL's IDEA
implementation as the backend though, but someone will
need to trawl through CPAN (for perl), the Linux dists
etc. to be sure.

MD2 is still present in the self-signature on some major
root certificates that are still trusted in signatures
on old/historic data and documents.  Note that the
default OpenSSL code currently skips checking the
self-signature on self-signed root certificates, but
that was done based as a workaround for the disabling
of MD2, and is based on the (unreliable) assumption
that checking their internal consistency had no value
in determining the trust.  Accepting MD2 only for this
limited role (and thus keeping the code around for that
case only) would be more secure.

The use of MD4 in NTLM is closely related to its use in
the password database format of computers that
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
extensions etc.  Those password databases and related
protocols will probably outlive NTLM itself by many
years.

WHIRLPOOL has been frequently recommended as the premier
non-NIST alternative to SHA-512, I have heard of no
reason to deprecate it.

The binary elliptic curve code in OpenSSL seems to have
a unique patent license heritage (via Sun I think) and
thus provides a unique source of such code for other
FOSS code as the Certicom and Sun patents change hands
in unpredictable ways.  I don't know if any major CA
issued ECDSA certificates using those curves, in which
case they remain important to the CMS and certificate
code in OpenSSL.  Again I have heard of no reason to
deprecate them.

I do not recall any common uses for the CAST cipher,
the MDC hash construct family or the RIPEMD hash
function family (at this time).

RC5 may be a patent problem and would probably be
disabled in most OpenSSL builds anyway.

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] How to access a bug fix ?

[jonetsu]

Hello,


 I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with 
no-rc2' although the opnssl tree I got recently does not show it:


% git status
On branch master
Your branch is up-to-date with 'origin/master'.


% git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a
fatal: bad object 92830dc1ca0bb2d12bf05a12ebb798709595fa5a


I tried with checking out a few branches:


  remotes/origin/OpenSSL-fips-2_0-stable
  remotes/origin/OpenSSL_1_0_1-stable
  remotes/origin/OpenSSL_1_0_2-stable


And still not shown.  Did that bug fix ever made it to the OpenSSL tree as 
such, or was it bundled in the 33,000+ lines commit 
7e1b7485706c2b11091b5fa897fe496a2faa56cc ?


Alternatively, in which 1.0.1 version was this bug fix included ?  I grepped 
the CHANGES file of some versions after 1.0.1e although these do not list the 
bug numbers.


Thanks.



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Elliptic curves approved or recommended by government

[Salz, Rich]

> Is there a up to date list of elliptic curves approved or recommended for 
> government use in OpenSSL?

You'll have to look outside OpenSSL for advice like that.

I would suggest looking at the CFRG, part of the IETF basically.  Do web search 
for curve recommendations.

Good luck.  It's a contentious area.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to access a bug fix ?

[Benjamin Kaduk]

On 11/13/2015 10:14 AM, jonetsu wrote:
> Hello,
>
>
>  I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with 
> no-rc2' although the opnssl tree I got recently does not show it:

The bug fix is just the patch contained in the initial submission.

>
> % git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
>
>
> % git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a
> fatal: bad object 92830dc1ca0bb2d12bf05a12ebb798709595fa5a
>
>
> I tried with checking out a few branches:
>
>
>   remotes/origin/OpenSSL-fips-2_0-stable
>   remotes/origin/OpenSSL_1_0_1-stable
>   remotes/origin/OpenSSL_1_0_2-stable

Checking out a different branch will not make any difference; "git show"
checks for all objects in a given repository, whether accessible from
the current HEAD or otherwise.

>
> And still not shown.  Did that bug fix ever made it to the OpenSSL tree as 
> such, or was it bundled in the 33,000+ lines commit 
> 7e1b7485706c2b11091b5fa897fe496a2faa56cc ?

It seems to be only in that mega-commit, which is not a real git merge
commit despite having 'merge' in the commit message.

>
> Alternatively, in which 1.0.1 version was this bug fix included ?  I grepped 
> the CHANGES file of some versions after 1.0.1e although these do not list the 
> bug numbers.
>

Looking at the pkcs12.c version in the OpenSSL_1_0_2-stable branch and
OpenSSL_1_0_1-stable branch, the bugfix is not present.  You would need
to apply it manually or convince a committer to push the change to the
stable branches.

-Ben Kaduk
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Benjamin Kaduk]

On 11/13/2015 09:31 AM, Jakob Bohm wrote:
> On 13/11/2015 14:40, Emilia Käsper wrote:
>> Hi all,
>>
>> We are considering removing from OpenSSL 1.1 known broken or outdated
>> cryptographic primitives. As you may know the forks have already done
>> this but I'd like to seek careful feedback for OpenSSL first to
>> ensure we won't be breaking any major applications.
>>
>> These algorithms are currently candidates for removal:
>>
>> CAST
>> IDEA
>> MDC2
>> MD2 [ already disabled by default ]
>> RC5 [ already disabled by default ]
>> RIPEMD
>> SEED
>> WHIRLPOOL
>> ALL BINARY ELLIPTIC CURVES
>>

I wonder why single-DES is not in the above list.  (Maybe because no one
has spoken up as being interested in disentangling triple-DES from
single-DES?)

>> My preference would be to remove these algorithms completely (as in,
>> delete the code). Disabled-by-default code will either be re-enabled
>> by distros (if there's widespread need for it - in which case we
>> might as well leave it in) or will be poorly tested and is likely to
>> just silently rot and break. This code is bloat and maintentance
>> burden for us - my hope is that much of this code is effectively dead
>> and can be removed.
>>

My hope as well :)
>> These algorithms are obsolete but removing them doesn't look feasible:
>>
>> BLOWFISH - probably still in use though I don't know where exactly?
>> MD4 - used in NTLM
>> RC2 - used in PKCS#12
>>

As another thread calls to mind, PKCS#12 could potentially just use
triple-DES.  (BTW, the CMS tests fail when openssl is configured with
no-rc2, due to this; I have a WIP patch sitting around.)

> MD2 is still present in the self-signature on some major
> root certificates that are still trusted in signatures
> on old/historic data and documents.  Note that the
> default OpenSSL code currently skips checking the
> self-signature on self-signed root certificates, but
> that was done based as a workaround for the disabling
> of MD2, and is based on the (unreliable) assumption
> that checking their internal consistency had no value
> in determining the trust.  Accepting MD2 only for this
> limited role (and thus keeping the code around for that
> case only) would be more secure.
>

I am not sure that I agree with the claim that this assumption is
unreliable.  There have been some (heated) discussions on the IETF tls
WG list recently regarding the self-signatures on trust anchors, and I
have not seen any compelling arguments there for checking the
self-signature.  The trust anchor is just a key and an identifier; its
presence in the trust store seems necessary and sufficient to me.

> The use of MD4 in NTLM is closely related to its use in
> the password database format of computers that
> interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
> extensions etc.  Those password databases and related
> protocols will probably outlive NTLM itself by many
> years.
>

The MD4 in the NTLM password hash is unsalted, for extra insecurity. 
The only real reason to still be using MD4 (by way of the RC4 enctype)
in Kerberos is if you need to interoperate with WinXP or Server 2003
machines, but those are not really supported anymore.  We are working to
get RC4 explicitly deprecated for Kerberos at the IETF.

-Ben Kaduk
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Protecting RSA keys

[Sergio Magra]

Hi everybody,

 

I'm new with OpenSSL and I have some questions.

 

The thing is that several RSA key pairs (each one for a
different user) will be stored in a shared secured location (Safenet HSM).
As the key pairs will be stored in the same place, we are looking for a way
to ensure that one user is able to use only its own key pair, and not the
key pair of another user.

 

In this way, I'm thinking on a passphrase to protect the
private key, so when the user needs to use its key pair for signing or
encrypting, he must provide the passphrase. As he knows its passphrase and
not the passphrase of the other key pairs, he is able to use only its own
key pair.

 

 

Until now, the theory. I don't know if I'm right.

 

Supposing that I'm right, I tried to generate protected key
pairs, but when using them, I'm never prompted for the passphrase. So, I'm
able to use any of the keys created, instead of using only my own key.

 

Can you help me with this issue?

 

 

Thanks in advance

 

Best regards

 

Sergio Magra   

 

 

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jakob Bohm]

On 13/11/2015 18:00, Benjamin Kaduk wrote:

On 11/13/2015 09:31 AM, Jakob Bohm wrote:

On 13/11/2015 14:40, Emilia Käsper wrote:

Hi all,

We are considering removing from OpenSSL 1.1 known broken or 
outdated cryptographic primitives. As you may know the forks have 
already done this but I'd like to seek careful feedback for OpenSSL 
first to ensure we won't be breaking any major applications.


These algorithms are currently candidates for removal:

CAST
IDEA
MDC2
MD2 [ already disabled by default ]
RC5 [ already disabled by default ]
RIPEMD
SEED
WHIRLPOOL
ALL BINARY ELLIPTIC CURVES



I wonder why single-DES is not in the above list.  (Maybe because no 
one has spoken up as being interested in disentangling triple-DES from 
single-DES?)


My preference would be to remove these algorithms completely (as in, 
delete the code). Disabled-by-default code will either be re-enabled 
by distros (if there's widespread need for it - in which case we 
might as well leave it in) or will be poorly tested and is likely to 
just silently rot and break. This code is bloat and maintentance 
burden for us - my hope is that much of this code is effectively 
dead and can be removed.




My hope as well :)

These algorithms are obsolete but removing them doesn't look feasible:

BLOWFISH - probably still in use though I don't know where exactly?
MD4 - used in NTLM
RC2 - used in PKCS#12



As another thread calls to mind, PKCS#12 could potentially just use 
triple-DES.  (BTW, the CMS tests fail when openssl is configured with 
no-rc2, due to this; I have a WIP patch sitting around.)



MD2 is still present in the self-signature on some major
root certificates that are still trusted in signatures
on old/historic data and documents.  Note that the
default OpenSSL code currently skips checking the
self-signature on self-signed root certificates, but
that was done based as a workaround for the disabling
of MD2, and is based on the (unreliable) assumption
that checking their internal consistency had no value
in determining the trust.  Accepting MD2 only for this
limited role (and thus keeping the code around for that
case only) would be more secure.



I am not sure that I agree with the claim that this assumption is 
unreliable.  There have been some (heated) discussions on the IETF tls 
WG list recently regarding the self-signatures on trust anchors, and I 
have not seen any compelling arguments there for checking the 
self-signature.  The trust anchor is just a key and an identifier; its 
presence in the trust store seems necessary and sufficient to me.



It is essentially a "proof-of-possession", just like the
signature on a CSR.  Another way to look at is that it is
a consistency check rather than a trust check.  One use
would be to refuse import of an invalid root CA before
even getting to the point of asking the user if she wants
to add this certificate to the trusted roots store.
Another use would be to detect accidental corruption of
the trusted roots store (e.g. from disk I/O errors or
partial disk writes during a system crash).


The use of MD4 in NTLM is closely related to its use in
the password database format of computers that
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
extensions etc.  Those password databases and related
protocols will probably outlive NTLM itself by many
years.



The MD4 in the NTLM password hash is unsalted, for extra insecurity.  
The only real reason to still be using MD4 (by way of the RC4 enctype) 
in Kerberos is if you need to interoperate with WinXP or Server 2003 
machines, but those are not really supported anymore.  We are working 
to get RC4 explicitly deprecated for Kerberos at the IETF.

I have not checked the details, but the fundamental issue is this:

Windows domain controller databases store only the unsalted
MD4 password hash and/or the historic LM password hash, with
most current systems configured to store only the MD4 hash.
 Thus any protocol that validates user identity via their
knowledge of their domain password would need to either
transmit the actual password to the domain controller or use
some kind of cryptographic calculation where the computer
closer to the user proves knowledge of the MD4 hash to the
domain controller server.   Historically, Microsoft has
implemented multiple such cryptographic protocols:

NTLMv1 was the oldest such protocol, based on a using DES in
a silly way vastly similar to the LM protocol.

NTLMv2 was the next version, based mostly on HMAC-MD5,
introduced in the late 1990s and still the strongest supported
when the client computer is not (yet) joined to the domain.

Microsoft-specific variants/profiles of Kerberos V are used
between modern (post 2000) domain joined computers and the
trusted domain controllers of the users login domain.  I have
not yet studied which formulas they are currently using/
recommending/planning for this case, but they will all be
constrained by the fact that the server knows nothing about
the password 

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jeffrey Walton]

> ALL BINARY ELLIPTIC CURVES

This one may be premature.

I understand the TLS WG is moving against it. However, I am aware of
implementations of Shoup's ECIES, and they, in turn, depend on
OpenSSL. I don't know if the ECIES implementations rely solely on
prime fields or not, however.

> BLOWFISH - probably still in use though I don't know where exactly?

Linux password files and associated tools, like John the Ripper (JtR).

OpenSSL is a good toolkit for research purposes. But if research is
not a goal, then that's understandable. There are other crypto
libraries that include research as a goal.

Jeff

On Fri, Nov 13, 2015 at 8:40 AM, Emilia Käsper  wrote:
> Hi all,
>
> We are considering removing from OpenSSL 1.1 known broken or outdated
> cryptographic primitives. As you may know the forks have already done this
> but I'd like to seek careful feedback for OpenSSL first to ensure we won't
> be breaking any major applications.
>
> These algorithms are currently candidates for removal:
>
> CAST
> IDEA
> MDC2
> MD2 [ already disabled by default ]
> RC5 [ already disabled by default ]
> RIPEMD
> SEED
> WHIRLPOOL
> ALL BINARY ELLIPTIC CURVES
>
> My preference would be to remove these algorithms completely (as in, delete
> the code). Disabled-by-default code will either be re-enabled by distros (if
> there's widespread need for it - in which case we might as well leave it in)
> or will be poorly tested and is likely to just silently rot and break. This
> code is bloat and maintentance burden for us - my hope is that much of this
> code is effectively dead and can be removed.
>
> Are you aware of any mainstream need to continue supporting these algorithms
> in OpenSSL 1.1? Note that an older OpenSSL library or binary, or a
> standalone implementation or another crypto toolkit can always be used to
> continue supporting a legacy standalone application, or to decrypt
> ciphertext from the distant past. I am looking for use cases that could
> cause e.g. interop breakage between new and old peers, or major pain to
> distro end-users.
>
> These algorithms are obsolete but removing them doesn't look feasible:
>
> BLOWFISH - probably still in use though I don't know where exactly?
> MD4 - used in NTLM
> RC2 - used in PKCS#12
>
> Did I miss anything from the list?
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] ECDHE Negotiation for Client but not Server

[Benn Bollay]

Hi folks -

Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications).

I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch)
that works fine for negotiating ECDHE-* ciphers as a client when talking to
an s_server, but fails as a server both when accepting connections from
itself or from s_client with a no shared cipher error.

You can download a full package to reproduce the issue at
http://www.magitech.org/gambit/ecdhetest.tar.gz

You can run the test by using make:

  $ make all

  $ make s_server & # Run’s OpenSSL s_server in the background

  $ make t_client # Runs the client - should be able to see the handshake
complete on the server’s log window.

  $ make t_server & # After killing the s_server, start up the test server

  $ make s_client # Fails to negotiate.

Any suggestions?
Cheers,
--B
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Dr. Stephen Henson]

On Fri, Nov 13, 2015, Benjamin Kaduk wrote:

> 
> As another thread calls to mind, PKCS#12 could potentially just use
> triple-DES.  (BTW, the CMS tests fail when openssl is configured with
> no-rc2, due to this; I have a WIP patch sitting around.)
> 

The issue is that some cuurent software (including major web browsers) still
produce PKCS#12 files which include 40 bit RC2 for certificate "encryption"
and OpenSSL would fail to decrypt those if it removed RC2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] (2013) : PKCS12 keystore creation failing in fips mode (RT3515)

[Dr. Stephen Henson]

On Wed, Nov 11, 2015, jonetsu wrote:

> Hello,
> 
> 
> There is a thread in 2013 (30 May 03:15) in which Steve writes that OpenSSL 
> 1.0.1 has a bug regarding the use of PKCS12 in FIPS mode since it tries to 
> handle a certificate using a non-FIPS component.  I think I found the commit 
> that fixes this, although it is part of a quite huge commit of 33,065 lines 
> (7e1b7485706c2b11091b5fa897fe496a2faa56cc) done earlier this year.  
> 
> 
> There is perhaps a simpler commit that fixes only this issue 
> (92830dc1ca0bb2d12bf05a12ebb798709595fa5a) although I can't see the commit in 
> the git tree I have fetched last week, even by branching to 
> remotes/origin/OpenSSL_1_0_1-stable.
> 
> 
> We are using 1.0.1.e.  My question is, was bug RT3515 included in a later 
> 1.0.1 release ?  If so, which one ?
> 

Try commit cdb6c48445ded3daafab32e5f266943d07bb512b

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Does openssl server always choose highest TLS version offered?

[Salz, Rich]

> Rfc5246 basically says that the server will choose the highest version but I 
> wanted to confirm that that's what openssl does (just to be certain).

That is what openssl does.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS 140-2, a game of chance

[Steve Marquess]

If you don't know or care what FIPS 140-2 is, trash this message quickly
before it harshes your mellow.

The "RE" validation, an "Alternative Scenario 1A" clone of the #1747
validation, was approved today
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473).

It was submitted along with its identical twin "RE" validation on April
17. The two sets of paperwork differed in only one trivial aspect, "RE"
in the module name for one versus "SE" for the other. Same module, same
test lab, same paperwork, submitted together at the same time. We could
not have devised a more perfect controlled study if we'd tried.

The "SE" validation was approved on June 25 (#2398), after a little more
than two months (69 calendar days, 48 working days).

The "RE" validation was not approved for almost seven months (210
calendar days, 145 working days). That's three times as long for the
exact same submission. I've had the experience for years now of doing
very similar validation submissions and noting very different outcomes,
but this is the most striking example yet of CMVP capriciousness.

Why the wild disparity? Well, probably because the two identical
submissions were farmed out to two different reviewers. The review
process is notoriously subjective, and in fact we received "comments"
(requirements for changes) for the "RE" validation whereas the "SE" one
was approved as-is. As a result the two Security Policy documents are no
longer identical. That doesn't explain the time discrepancy, though, as
those "comments" weren't received until long after "SE" had been approved.

The moral here is that FIPS 140-2 validations are a crapshoot; it's
impossible to make any reliable predictions on how long any validation
action will take or how it will be received. If you have really deep
pockets you can submit the same validation multiple times to hedge your
bets (we've actually done that[1]), but for most of us it's an open
ended gamble: submit, hope, wait, ...

-Steve M.

[1] See http://veridicalsystems.com/blog/the-fickleness-of-fips/; note
that dual submission did pay off for that client.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ECDHE Negotiation for Client but not Server

[Benn Bollay]

Sorted; needed to call SSL_CTX_set_tmp_ecdh with my private EC_KEY.  Can
someone express an opinion if using my private key is acceptable there, or
if I should generate a new one from a named curve each time I create a
context?

Cheers,
--B

On Fri, Nov 13, 2015 at 11:21 AM, Benn Bollay  wrote:

> Hi folks -
>
> Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications).
>
> I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch)
> that works fine for negotiating ECDHE-* ciphers as a client when talking to
> an s_server, but fails as a server both when accepting connections from
> itself or from s_client with a no shared cipher error.
>
> You can download a full package to reproduce the issue at
> http://www.magitech.org/gambit/ecdhetest.tar.gz
>
> You can run the test by using make:
>
>   $ make all
>
>   $ make s_server & # Run’s OpenSSL s_server in the background
>
>   $ make t_client # Runs the client - should be able to see the handshake
> complete on the server’s log window.
>
>   $ make t_server & # After killing the s_server, start up the test server
>
>   $ make s_client # Fails to negotiate.
>
> Any suggestions?
> Cheers,
> --B
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Rehandshake problem

[Matt Caswell]

On 13/11/15 08:37, Ignacio Casal wrote:
> Hey guys,
> 
> I am having a specific problem that I do not seem to find a solution for.
> 
> - I have a server and a client that handshake properly
> - the server will read from the client and the client from the server a
> few bytes
> - the client will try to read again
> - the server will try to handshake again by calling SSL_renegotiate and
> SSL_do_handshake. I get no errors in these calls.
> - then I would expect the client to exit from the read call with an
> error saying that needs to handshake again, instead it stays blocked on
> the read until the server sends some data. But then I get an error
> server side that there was no proper handshaking.
> 
> Do you know how to get a notification client side that the client needs
> to handshake again when blocked on a read or write?

Which OpenSSL version/platform are you using? Can you get a pcap packet
trace and post the specific errors that you are receiving?

You would normally expect to get an SSL_ERROR_WANT_READ on the client
side when the server sends the HelloRequest.

Matt

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format

[Peter P.]

Hi Wim,

I'll give this a shot, thank you for the suggestion!

-Peter

On Wed, Nov 11, 2015 at 5:05 PM, Wim Lewis  wrote:

>
> On Nov 9, 2015, at 3:46 PM, Peter P.  wrote:
> > I'm writing an application using Openssl 1.0.2d where I am trying to
> take a DER encoded unsigned CSR and read it into an X509_REQ data structure
> via the d2i_X509_REQ_bio() function. This function errors out during when I
> attempt to read in my unsigned CSR and I would like to know if there is any
> other way to read in an unsigned CSR into an X509_REQ data structure.
>
> A CSR (from PKCS#10 / RFC2986) has the structure:
>
>SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING }
>
> where the actual request is the CertificationRequestInfo, and the
> signature is composed of the AlgorithmIdentifier + BIT STRING.
>
> Are you trying to just read in a bare CertificationRequestInfo structure?
> I suspect you can do that with a call like
>
> ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req)
>
> which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ
> replaced by X509_REQ_INFO. I haven't tried it, though.
>
> (Whether it's a *good idea* to pass bare CSR info structs around is
> another question but I'll leave that up to you.)
>
>
> Wim.
>
> ___
> 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] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Emilia Käsper]

Hi all,

We are considering removing from OpenSSL 1.1 known broken or outdated
cryptographic primitives. As you may know the forks have already done this
but I'd like to seek careful feedback for OpenSSL first to ensure we won't
be breaking any major applications.

These algorithms are currently candidates for removal:

CAST
IDEA
MDC2
MD2 [ already disabled by default ]
RC5 [ already disabled by default ]
RIPEMD
SEED
WHIRLPOOL
ALL BINARY ELLIPTIC CURVES

My preference would be to remove these algorithms completely (as in, delete
the code). Disabled-by-default code will either be re-enabled by distros
(if there's widespread need for it - in which case we might as well leave
it in) or will be poorly tested and is likely to just silently rot and
break. This code is bloat and maintentance burden for us - my hope is that
much of this code is effectively dead and can be removed.

*Are you aware of any mainstream need to continue supporting these
algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary,
or a standalone implementation or another crypto toolkit can always be used
to continue supporting a legacy standalone application, or to decrypt
ciphertext from the distant past. I am looking for use cases that could
cause e.g. interop breakage between new and old peers, or major pain to
distro end-users.

These algorithms are obsolete but removing them doesn't look feasible:

BLOWFISH - probably still in use though I don't know where exactly?
MD4 - used in NTLM
RC2 - used in PKCS#12

*Did I miss anything from the list?*

Cheers,
Emilia
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to get list of TLS protocols supported by OpenSSL?

[Jakob Bohm]

On 13/11/2015 10:34, Matt Caswell wrote:

On 13/11/15 02:56, pratyush parimal wrote:

Hi,

I'm writing a client-server program that uses TLS for communication.
I'm wondering if there's any way to programmatically find out which TLS
protocol versions are supported by the OpenSSL library installed on my
system.

I'm currently aware of three ways which "sort of" provide this information:
(1) After setting up the TLS communication, call: SSL_get_version(ssl);
which returns "TLSV1.2", etc.
(2) Try to connect to a server using TLS by specifying all possible TLS
versions in the client program, and see which connections pass/fail.
(3) Call: SSL_get_ciphers(), print their names, and try to correlate
them with the protocol they're associated with.

Unfortunately, none of the above answer my question completely.

So is it possible to ascertain which TLS protocol versions are actually
supported by my server-program, without trying the above methods? My
purpose is not to simply make a list for my own reference, but rather
finding it out on-the-fly in the server-side program, since I may run it
on different versions of OpenSSL.

You can use the define TLS_MAX_VERSION to determine the highest protocol
version supported by the library.

If you also want to know the lowest version then that's a bit more
tricky. All current released versions will define OPENSSL_NO_SSL3 if
SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2
support has been compiled out (its not currently possible to compile out
other protocol versions). In the forthcoming 1.1.0 release SSLv2 support
has been completely removed so you don't get OPENSSL_NO_SSL2 even though
there is no SSLv2 support available (h...I wonder if we should add
that?). There are other SSLv2 defines in ssl2.h that are removed in
1.1.0 which you could use to detect whether you are on a version with
ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like
(completely untested):

#ifdef OPENSSL_NO_SSL3
#define TLS_MIN_VERSION TLS1_VERSION
#elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR)
#define TLS_MIN_VERSION SSL3_VERSION
#else
#define TLS_MIN_VERSION SSL2_VERSION
#endif

How future proof that is if we ever remove SSLv3 support I'm not sure.

Matt

Unfortunately that presumes that the client is compiled
against configure headers from the library build.

This is absolutely useless if you try to share an OpenSSL
shared library compiled by a 3rd party (such as an OS
distribution or an end user).

What lots of people need is an ability to interrogate a
compiled shared library about what is enabled in that copy,
similar to how the SSL_get_ciphers() or similar can be used
to determine if the current copy has been compiled without
IDEA, ECC or other optional cipher suites.

This is what happens in the real world when end users run your
compiled program on various Linux distributions, such as Red
Hat vs. OpenSUSE vs. Ubuntu...

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

Re: [openssl-users] Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d?

[hebertpj]

Thank you kindly Matt, for the pointers - these connections always end with
that renegotiation and subsequent failure - I suspect there is a ciphersuite
problem and am following up to see what the client *will* support.Paul H.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Broken-ChangeCipherspec-record-in-TLS-1-2-with-OpenSSL-1-0-2d-tp59592p60972.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users