Re: [openssl-users] CSR with multiple subject names?

[Jakob Bohm]

On 01/06/2017 16:26, l vic wrote:
I am working with service with TLS authn that uses subject name to 
authenticate client.
Is it possible to use list of subject names in client certificate so 
that service could authenticate several clients with the same 
key/certificate? If not, would it be possible to use alternative 
subject names for the same purpose? Can SANs only used in the context 
of DNS domains, eg to authenticate the same subject name calling from 
different DNS domains?

SANs (SubjectAlternativeNames) can contain all the name types
(unlike the main Subject, which can only contain a backwards
compatible DirectoryName).

Depending on what kind of identity a server wants to identify,
good choices for user identifying SANs are:

 - rfc822Name ("u...@sub.domain.tld")
 - DirectoryName (CN=First Middle Last, OU=Department, O=Example 
company, street=SomeRoad 123, L=12345 SomeCity, ST=SomeState, C=US)


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] OpenSSL version 1.0.2l published

[Viktor Dukhovni]

> On Jun 1, 2017, at 10:54 AM, Wouter Verhelst  
> wrote:
> 
> It might be useful to make that point at the start of the CHANGES file,
> then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
> [date]". While that doesn't claim to be complete, the simple word
> "CHANGES" invokes the idea of a changelog, which should be complete --
> and this file is not. If it's not meant to be, fine -- but then it
> doesn't hurt to say so, and it would alleviate some confusion.

Sure, would "Major changes" be sufficient?  This is essentially
a RELEASE_NOTES file, not a comprehensive change log, which is
subsumed by git.

-- 
Viktor.

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

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 12:23, Michael Wojcik wrote:


On the other hand, this doesn't really answer Florin's question of why
the server sees so many clients falling back. If the load is bursty,
it might be listen-queue dumping. I don't know if Nginx lets you
configure the listen queue depth, but at some point the stack will
start dropping connections (either silently, in the BSD or "correct"
manner; or with a RST, in the Winsock or "patently wrong" manner) if
the sustained load is too high. But unless this is a pretty busy
server or has a really high variance in its load distribution, it's
probably an intermediary node that's to blame.


Aggregate traffic has a smooth profile, with daily increase towards the 
middle of the day, and decrease towards midnight. Client sessions are 
typically short (way under 1 minute, perhaps most of them under 15 
seconds).


I don't see any errors related to what you're saying.


Or the clients have a really short timeout, or the connection's being
aborted by the user and the client is incorrectly falling back when
that happens. Though then I'd assume Florin would see that in the
Nginx logs, assuming it logs ECONNRESET.


Well, I'm digging through the logs. The one thing I see often is:

client X.Y.Z.K closed keepalive connection

Not much other than that, and these are really "severity:info" events, I 
see them even with TLS termination at the ALB.


I see some amount of...

peer closed connection in SSL handshake while SSL handshaking

...also a "severity:info" event, at a rate about 4x less than the 
“inappropriate fallback” stuff.


(shrug) Seems normal.

As a more informal argument: We're using whatever Amazon deemed 
appropriate for their TLS policy for load balancers, in terms of 
protocol versions and ciphers. Surely if there was a problem with 
versions or ciphers, we'd hear about it, or they would change it 
quickly, just based on the amount of traffic they receive every day. 
That was the main reason why I've found hard to accept that this rate of 
TLS errors is somehow normal; but now I think I start to understand this 
aspect of the protocol thanks to the excellent explanations I've seen 
early in this discussion.


--
Florin Andrei
http://florin.myip.org/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems

[共通基盤ＳＳＬ［業務ＩＤ］ / COMMONSSL，GYOUMU]

Hello All.

Sorry for the late reply.

I understood.

Thank you very much.

Best regards,
and I'll try that.

Manabu


> On May 12, 2017, at 5:00 PM, Michael Wojcik 
> wrote:
> 
> >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> >> Behalf Of Thomas Francis, Jr.
> >> Sent: Friday, May 12, 2017 15:55
> >>
> >>> On 5/10/17 3:55 AM, 共通基盤ＳＳＬ［業務ＩＤ］ / COMMONSSL，GYOUMU
> wrote:
> >>>
> >>> I will build OpenSSL on SUSE Linux Enterprise Server for z Systems.
> >
> > What version of OpenSSL?
> >
> >>> But, there is not yet the machine for build, so I cannot do actual
> >>> machine verification.
> >>>
> >>> The CPU is not Intel architecture, is probably z/Architecture.
> >
> > Yes, Linux for System z runs on z-architecture CPUs.
> >
> >>> I want to know beforehand the appropriate command-line parameters
> >>> for executing "Configure".
> >>>
> >>> Is it right to specify "linux64-s390x" as follows?
> >>>
> >>> (1)cd //openssl-1.0.2k
> >>>
> >>> (2)./Configure linux64-s390x
> >>
> >> I'd suggest just running "./config".  That will pick the appropriate
> >> 64-bit target.  Only use Configure if you want to do something
> >> non-standard. :)
> >
> > That's certainly the place to start. Whether it will work is another
> question.
> >
> > When we build OpenSSL for z Linux (RHEL and SLES), we use a modified
> Configure that:
> >
> > * Adds -fPIC and -mbackchain. This is because we compile OpenSSL into
> an archive library that is then linked into a shared object, so we have
> to force on the shared-object flags in Configure.
> >
> > * Replaces -O3 with -O1, preferring robustness (or, if you prefer,
> toleration for sloppiness and error) and ease of problem determination over
> performance.
> >
> > * Replaces the asm setting[1] with ${no_asm}, for the same reason.
> >
> > * For 32-bit, removes /highgprs. According to my notes, highgprs does
> not work correctly with some glibc versions on zLinux.
> >
> > The OP probably doesn't need the first three and may well not need the
> last. Depending on how clever one gets with building and using OpenSSL,
> though, config+Configure aren't always sufficient as supplied. That's not
> a criticism - trying to accommodate every use case is not a good use of
> the OpenSSL development team's time.
> >
> > But unless you're happy with the default build parameters and comfortable
> with your platform, be prepared to learn how the OpenSSL build works.
> 
> I think in general, the same caveat applies for any system. The default
> build settings might not be what you want. But in most cases (including
> Linux for z), they will get you libraries that'll work with the system
> compiler toolchain if you pass only the minimum flags to specify where the
> headers and libraries can be found.
> 
> I figure if you need something else you probably already know that, and
> can pass the appropriate flags in CFLAGS, CPPFLAGS, or LDFLAGS. :) Or create
> a custom target.
> 
> TOM
> 
> PS Regarding highgprs; I suspect that's actually a problem of mixing 32-bit
> s390x binaries with s390 binaries. There is a difference.  But old bugs
> and miscommunication means that sometimes the s390 system will think it
> can load an s390x binary (and sometimes think it succeeded). :)
> 
> > [1] There are two zLinux targets in the 1.0.2 Configure, for 64- and 32-bit.
> The linux64-s390x target uses ${s390x_asm} for its asm section, but the
> linux32-s90x uses an eval expression that edits $s390x_asm. We disable asm
> for both.
> >
> >
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus

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

Re: [openssl-users] CSR with multiple subject names?

[Salz, Rich via openssl-users]

By default, TLS only does server-side verification.  If you are using client 
certificates, you will have to write some code for your application.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Matt Caswell]

On 25/05/17 15:29, Dennis Clarke wrote:
> 
> So this is exclusively a change to support mingw64 ?

Sorry, I missed this email somehow. This release rolls up numerous bug
fixes that have been implemented since the last release. We only put
particularly significant items in CHANGES.

Matt


> 
> That seems to be all that is said here :
> 
> https://www.openssl.org/news/cl102.txt
> 
> 
> 
>  OpenSSL CHANGES
>  ___
> 
>  Changes between 1.0.2l and 1.0.2m [xx XXX ]
> 
>   *)
> 
>  Changes between 1.0.2k and 1.0.2l [25 May 2017]
> 
>   *) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the
> target
>  platform rather than 'mingw'.
>  [Richard Levitte]
> 
> 
> .
> .
> .
> 
> 
> Dennis Clarke
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Making a CRL with an authority key identifier

[Ivan Rubinson]

Hello,

My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an
authority key identifier.
(a third party API expects it from the CRL)

I make my own CA, use it to sign a certificate, and then generate the CRL.
This is the configuration file: https://pastebin.com/yL4UBtGW (it's
basically the example configuration file with a few changes).

Here are the commands I run:
Making the CA:

> openssl req -new -x509 -days 3650 -extensions v3_ca -keyout
> private/cakey.pem -out cacert.pem -config req.cnf
>
Making the certificate:

> openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem
> -config req.cnf
> openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem
>
Making the CRL:

> openssl ca -config req.cnf -gencrl -out crl.pem
>

I'm using OpenSSL-Win64 0.9.8g

Even though on line 251 I ask OpenSSL to have an authority key identifier,
the generated CRL doesn't have it. I've searched on google and tried
multiple things (like uncommenting issuerAltName, or giving it different
options) and the CRL still doesn't have it.
At this point I'm stumped, and I'd like to ask you nice people for help.


Thank you in advance,
Ivan Rubinson


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Matt Caswell]

On 01/06/17 02:58, Florin Andrei wrote:
> It's a little puzzling because the exchange of crypto messages uses TLS
> 1.0 which the server definitely supports, and the client should be very
> likely to support too.
> 
> I've seen discussions online saying that the presence of the
> TLS_FALLBACK_SCSV cipher suite is an indication that this failed
> connection is related to anti-POODLE security measures, and the
> communication is likely to be retried again. Is that correct?

"Normal" TLS version negotiation works like this (ignoring TLSv1.3 which
isn't relevant for this discussion): the client sends the maximum TLS
version that it supports in its ClientHello message (this should not be
confused with the version number in the record header). The server
responds with a ServerHello containing the maximum version that it
supports and which is less than or equal to the client's maximum version
number.

For example, if the client supports TLSv1.2 but the server only supports
TLSv1.0, then the ClientHello version will be TLSv1.2 and the server
will respond with TLSv1.0. On the other hand if the client only supports
TLSv1.0 but the server supports TLSv1.2, then the ClientHello version
will be TLSv1.0 and the ServerHello version will also be TLSv1.0.

This is all fine but there are some servers out there which are buggy
and abort the connection if the ClientHello version is bigger than the
maximum version that the server supports. To work around this some
clients will do "fallback". So, they start with a ClientHello version of
TLSv1.2. If the connection aborts then they might send another one with
a version of TLSv1.1. If that aborts then TLSv1.0.

The problem with that approach is that it can be exploited by an
attacker. An attacker may be able to exploit some weakness in an earlier
TLS version which is fixed in a later version. The attacker may then be
able to modify the traffic to ensure that a TLSv1.2 ClientHello fails in
order to force the client to fallback to the earlier exploitable version.

The TLS_FALLBACK_SCSV ciphersuite is used as a counter measure to that
type of attack. A client will include it if it is sending a ClientHello
with a max version that is lower than the maximum that the client
actually supports (because an earlier attempt with the higher version
number failed). If a server receives a TLS_FALLBACK_SCSV ciphersuite in
a ClientHello and it supports a higher version than the one in the
ClientHello then there should have been no reason for the client to
fallback and you get the "inappropriate fallback" error.

The presence of this error doesn't actually mean that you are under
attack. It just means that the client made an earlier connection attempt
with a higher version number and it failed. There could be many reasons
for the failure. For example, plausibly, if you have a lot of mobile
clients then you could imagine that a network glitch could cause an
earlier attempt to fail.

Matt



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

Re: [openssl-users] Making a CRL with an authority key identifier

[Juan Angel Martin (AC Camerfirma)]

Hi,

 

Uncomment line 54

crl_extensions= crl_ext

 

BR 

Juan Ángel

 

De: openssl-users [mailto:openssl-users-boun...@openssl.org] En nombre de Ivan 
Rubinson
Enviado el: jueves, 1 de junio de 2017 12:15
Para: openssl-users@openssl.org
Asunto: [openssl-users] Making a CRL with an authority key identifier

 

Hello,

My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an authority 
key identifier.

(a third party API expects it from the CRL)

I make my own CA, use it to sign a certificate, and then generate the CRL. This 
is the configuration file: https://pastebin.com/yL4UBtGW (it's basically the 
example configuration file with a few changes).

Here are the commands I run:

Making the CA:

openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/cakey.pem 
-out cacert.pem -config req.cnf

Making the certificate:

openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem -config 
req.cnf
openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem

Making the CRL:

openssl ca -config req.cnf -gencrl -out crl.pem

 

I'm using OpenSSL-Win64 0.9.8g

Even though on line 251 I ask OpenSSL to have an authority key identifier, the 
generated CRL doesn't have it. I've searched on google and tried multiple 
things (like uncommenting issuerAltName, or giving it different options) and 
the CRL still doesn't have it.

At this point I'm stumped, and I'd like to ask you nice people for help.



Thank you in advance,

Ivan Rubinson

 


 

 

Virus-free.  

 www.avast.com 

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e?

[Matt Caswell]

On 31/05/17 21:22, Siyuan Xiang wrote:
> Hi all, 
> 
> I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher. 
> 
> I have a client using openssl 1.1.0e. It doesn't include
> TLS_RSA_WITH_RC4_128_MD5. 
> I have recompiled the openssl using  enable-weak-ssl-ciphers, but it
> doesn't work
> but  TLS_RSA_WITH_RC4_128_SHA  is in client hello message. 
> 
> It looks like all MD5 related ciphers are removed.  I tried to
> use SSL_CTX_set_security_level to 
> set level to 0. but it doesn't work. 
> 
> Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5? 

How have you configured your ciphersuite list? I can get this to work in
1.1.0 using s_server and s_client.

Having built with "enable-weak-ssl-ciphers" I start up s_server like this:

$ openssl s_server -cipher "RC4-MD5:@SECLEVEL=0"

And then run s_client like this:

$ openssl s_client -cipher "RC4-MD5:@SECLEVEL=0"

The connection is successful and uses the RC4-MD5 ciphersuite (aka
TLS_RSA_WITH_RC4_128_MD5).

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

Re: [openssl-users] Making a CRL with an authority key identifier

[Ivan Rubinson]

Aha, I can't believe I missed that.
That's why an extra pair of fresh eyes is helpful.
Thank you Juan. I'll test this now.

On Thu, Jun 1, 2017 at 1:22 PM, Juan Angel Martin (AC Camerfirma) <
martin...@camerfirma.com> wrote:

> Hi,
>
>
>
> Uncomment line 54
>
> crl_extensions= crl_ext
>
>
>
> BR
>
> Juan Ángel
>
>
>
> *De:* openssl-users [mailto:openssl-users-boun...@openssl.org] *En nombre
> de *Ivan Rubinson
> *Enviado el:* jueves, 1 de junio de 2017 12:15
> *Para:* openssl-users@openssl.org
> *Asunto:* [openssl-users] Making a CRL with an authority key identifier
>
>
>
> Hello,
>
> My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an
> authority key identifier.
>
> (a third party API expects it from the CRL)
>
> I make my own CA, use it to sign a certificate, and then generate the CRL.
> This is the configuration file: https://pastebin.com/yL4UBtGW (it's
> basically the example configuration file with a few changes).
>
> Here are the commands I run:
>
> Making the CA:
>
> openssl req -new -x509 -days 3650 -extensions v3_ca -keyout
> private/cakey.pem -out cacert.pem -config req.cnf
>
> Making the certificate:
>
> openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem
> -config req.cnf
> openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem
>
> Making the CRL:
>
> openssl ca -config req.cnf -gencrl -out crl.pem
>
>
>
> I'm using OpenSSL-Win64 0.9.8g
>
> Even though on line 251 I ask OpenSSL to have an authority key identifier,
> the generated CRL doesn't have it. I've searched on google and tried
> multiple things (like uncommenting issuerAltName, or giving it different
> options) and the CRL still doesn't have it.
>
> At this point I'm stumped, and I'd like to ask you nice people for help.
>
> Thank you in advance,
>
> Ivan Rubinson
>
>
>
>
> 
>
> Virus-free. www.avast.com
> 
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Wouter Verhelst]

On 01-06-17 16:40, Matt Caswell wrote:
> CHANGES is what it is - a list of changes we thought were particularly
> worthy of note. If that's not enough information for you then use the
> git logs. I see very little value in automatically extracting info out
> of the logs and including it in the distribution when the logs are so
> easily accessible elsewhere.

It might be useful to make that point at the start of the CHANGES file,
then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
[date]". While that doesn't claim to be complete, the simple word
"CHANGES" invokes the idea of a changelog, which should be complete --
and this file is not. If it's not meant to be, fine -- but then it
doesn't hurt to say so, and it would alleviate some confusion.

Thanks,

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

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 02:13, Matt Caswell wrote:


The presence of this error doesn't actually mean that you are under
attack. It just means that the client made an earlier connection 
attempt

with a higher version number and it failed. There could be many reasons
for the failure. For example, plausibly, if you have a lot of mobile
clients then you could imagine that a network glitch could cause an
earlier attempt to fail.


It's interesting how I see a constant stream of “inappropriate fallback” 
errors in the logs, but this is pretty much the only error from a TLS 
perspective. Sure, there's the occasional certificate failure, like once 
every few minutes or so, and then, rarely, there's some ancient app 
trying SSLv3 (which is not enabled). But looking at the Nginx error.log 
the “inappropriate fallback” is basically the only error I get a 
perpetual flow of.


If the TLS_FALLBACK_SCSV attempt is caused by a previously failed 
connection, that must have been something different from a TLS error, 
because “inappropriate fallback” is probably over 99% of the lines in 
error.log - it's the only thing I see as logs are scrolling up in my 
viewer.


Would clients actually attempt to send TLS_FALLBACK_SCSV even if the 
previous connection attempt failed for reasons other than TLS? If, say, 
the initial connection attempt failed at the TCP level? That sounds a 
little strange to me.


Again, our clients are a mix of the average mobile devices in general 
use these days.


--
Florin Andrei
http://florin.myip.org/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 11:43, Salz, Rich via openssl-users wrote:

Would clients actually attempt to send TLS_FALLBACK_SCSV even if the
previous connection attempt failed for reasons other than TLS? If, 
say, the
initial connection attempt failed at the TCP level? That sounds a 
little strange

to me.


Yes they do.

There are many badly written clients out there.  Or poor libraries.


What I find surprising is the rate of these errors. For every 100 
legitimate HTTP requests that make it to Nginx, I get 2.5 “inappropriate 
fallback” SSL errors. That's a lot of noise.


I guess I'll have to adjust my expectations.

Related question: assuming the lists of TLS protocol versions and 
ciphers I've enabled in Nginx are indeed exactly the same as the default 
TLS policy in an AWS ALB, the errors I see now logged by Nginx should 
be, more or less, the same population of errors I saw reflected in the 
ALB metrics before, right? The whole point of this exercise is to 
temporarily work around the lack of a TLS error log in an ALB. The error 
rate does seem quite similar between ALB and Nginx. I'm just wondering 
if the ALB is doing something that my standard Ubuntu openssl libraries 
are not.


--
Florin Andrei
http://florin.myip.org/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Salz, Rich via openssl-users]

> Would clients actually attempt to send TLS_FALLBACK_SCSV even if the
> previous connection attempt failed for reasons other than TLS? If, say, the
> initial connection attempt failed at the TCP level? That sounds a little 
> strange
> to me.

Yes they do.

There are many badly written clients out there.  Or poor libraries.

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

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Salz, Rich via openssl-users]

> What I find surprising is the rate of these errors. For every 100 legitimate
> HTTP requests that make it to Nginx, I get 2.5 “inappropriate fallback” SSL
> errors. That's a lot of noise.
> 
> I guess I'll have to adjust my expectations.

That's not out of line with other measurements I've been told.
 
> Related question: assuming the lists of TLS protocol versions and ciphers I've
> enabled in Nginx are indeed exactly the same as the default TLS policy in an
> AWS ALB, the errors I see now logged by Nginx should be, more or less, the
> same population of errors I saw reflected in the ALB metrics before, right?

Not necessarily.  The network connectivity could be a very large influence.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Thursday, June 01, 2017 14:44
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] SSL error “inappropriate fallback” and 
> TLS_FALLBACK_SCSV
> 
> > Would clients actually attempt to send TLS_FALLBACK_SCSV even if the
> > previous connection attempt failed for reasons other than TLS? If, say, the
> > initial connection attempt failed at the TCP level? That sounds a little 
> > strange
> > to me.
> 
> Yes they do.

And they should, *if* they have actually fallen back to an older protocol 
version, because an attacker with the appropriate affordance (e.g. a 
compromised router along the path) could easily trigger a TCP failure by 
sending a RST. Any time the client falls back, it should include 
TLS_FALLBACK_SCSV in its cipher-suite list.

The question is whether a client that supports fallback (and there's much 
debate over whether clients should support fallback, particularly in the 
default configuration) ought to try falling back in response to a TCP failure. 
On the one hand, it's entirely possible that a broken old server would reject 
an unrecognized protocol version by simply aborting the connection. On the 
other, there are a lot of other reasons for a RST, and falling back as the 
first resort seems rather hasty.

Personally, I'd prefer clients not try to fall back at all, except perhaps 
clients that have a reasonable need to support broken servers, and even then 
only with some non-default configuration. Browser manufacturers will argue that 
they have to support fallback in order to support broken web servers, but I 
think that's dubious.

> There are many badly written clients out there.  Or poor libraries.

Very true.

On the other hand, this doesn't really answer Florin's question of why the 
server sees so many clients falling back. If the load is bursty, it might be 
listen-queue dumping. I don't know if Nginx lets you configure the listen queue 
depth, but at some point the stack will start dropping connections (either 
silently, in the BSD or "correct" manner; or with a RST, in the Winsock or 
"patently wrong" manner) if the sustained load is too high. But unless this is 
a pretty busy server or has a really high variance in its load distribution, 
it's probably an intermediary node that's to blame.

Or the clients have a really short timeout, or the connection's being aborted 
by the user and the client is incorrectly falling back when that happens. 
Though then I'd assume Florin would see that in the Nginx logs, assuming it 
logs ECONNRESET.

Really there are too many possibilities to make speculation worthwhile. But now 
that I've written all this I suppose I'll send it.

Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e?

[Siyuan Xiang]

Hi Matt,

I tried the following command, it failed.  following is my command.

./config enable-weak-ssl-ciphers --prefix=/opt
make
make DESTDIR=/path/to/dir INSTALL

$ ./openssl version
OpenSSL 1.1.0e  16 Feb 2017

./openssl s_client -cipher "RC4-MD5:@SECLEVEL=0"

error setting cipher list
140369010624144:error:140E6118:SSL
routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1337:


./openssl ciphers "RC4-MD5:@SECLEVEL=0"
Error in cipher list
140458428679936:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no
cipher match:ssl/ssl_lib.c:2018:

However, after I change  SSL_CTX_set_XXX function orders,
TLS_RSA_WITH_RC4_128_MD5
do appear in client hello cipher list.

SSL_CTX_set_security_level(ctx, 0);
SSL_CTX_set_cipher_list(ctx, "ALL:RC4-MD5");

Regards,
Siyuan
---

On Thu, Jun 1, 2017 at 2:41 AM, Matt Caswell  wrote:

>
>
> On 31/05/17 21:22, Siyuan Xiang wrote:
> > Hi all,
> >
> > I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher.
> >
> > I have a client using openssl 1.1.0e. It doesn't include
> > TLS_RSA_WITH_RC4_128_MD5.
> > I have recompiled the openssl using  enable-weak-ssl-ciphers, but it
> > doesn't work
> > but  TLS_RSA_WITH_RC4_128_SHA  is in client hello message.
> >
> > It looks like all MD5 related ciphers are removed.  I tried to
> > use SSL_CTX_set_security_level to
> > set level to 0. but it doesn't work.
> >
> > Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5?
>
> How have you configured your ciphersuite list? I can get this to work in
> 1.1.0 using s_server and s_client.
>
> Having built with "enable-weak-ssl-ciphers" I start up s_server like this:
>
> $ openssl s_server -cipher "RC4-MD5:@SECLEVEL=0"
>
> And then run s_client like this:
>
> $ openssl s_client -cipher "RC4-MD5:@SECLEVEL=0"
>
> The connection is successful and uses the RC4-MD5 ciphersuite (aka
> TLS_RSA_WITH_RC4_128_MD5).
>
> 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] OpenSSL version 1.0.2l published

[Matt Caswell]

On 01/06/17 15:17, Dennis Clarke wrote:
> On 06/01/2017 09:53 AM, Salz, Rich via openssl-users wrote:
>>>   So the CHANGES file isn't really "changes".
>>
>> The full list of everything that has changed can be found via git
>> logs.  As Matt said, we only put particularly significant items in the
>> CHANGES file.
>>
>>
> 
> Why?
> 
> Why isn't the list of changes dumped into a simple text file and
> included in the source release tarball ?   Consider users and systems
> which do not have git installed by default.  For that matter, git does
> not exist or even compile on those target systems but openssl most
> certainly does.

They are easily obtainable even if you do not have git. The list for
1.0.2l is here:

https://github.com/openssl/openssl/commits/OpenSSL_1_0_2l

Matt

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

[openssl-users] CSR with multiple subject names?

[l vic]

I am working with service with TLS authn that uses subject name to
authenticate client.
Is it possible to use list of subject names in client certificate so that
service could authenticate several clients with the same key/certificate?
If not, would it be possible to use alternative subject names for the same
purpose? Can SANs only used in the context of DNS domains, eg to
authenticate the same subject name calling from different DNS domains?
Thank you,
lvic
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Dennis Clarke]

They are easily obtainable even if you do not have git. The list for
1.0.2l is here:

https://github.com/openssl/openssl/commits/OpenSSL_1_0_2l


( point missed )

The issue is that the CHANGES file simply isn't.  The most recent for
1.0.2l being truely spartan. If this were vim or perhaps nano or even
grep then I would go digging. However in these times of ever more
security concerns for our servers I feel[1] that the openssl source
release should at least have a trivial text list with more data than this :

sedna$ git diff --stat --color OpenSSL_1_0_2l..OpenSSL_1_0_2k
 .travis.yml|   1 +
 CHANGES|   6 -
 Configure  |  19 +-
 LICENSE|   4 +-
 Makefile.org   |   8 -
 NEWS   |   4 -
 README |   2 +-
 TABLE  |  58 +--
 apps/ca.c  |  19 +-
 apps/dhparam.c |  24 +-
 apps/enc.c |  33 +-
 apps/engine.c  |   9 +-
 apps/pkeyutl.c |   4 +-
 apps/prime.c   |   3 -
 apps/progs.h   |   2 +-
 apps/progs.pl  |  30 +-
 apps/req.c |   6 +-
 apps/s_client.c|   1 -
 apps/s_server.c|   1 -
 apps/srp.c |   4 +-
 appveyor.yml   |   8 +
 config |   9 -
 crypto/aes/Makefile|   2 +-
 crypto/aes/asm/aesni-sha1-x86_64.pl|   1 -
 crypto/aes/asm/aesni-sha256-x86_64.pl  |   1 -
 crypto/aes/asm/bsaes-armv7.pl  |   2 +-
.
.  etc etc
.
 util/domd  |   6 +-
 util/mk1mf.pl  |   1 -
 148 files changed, 756 insertions(+), 1520 deletions(-)
sedna$

Dennis

[1] yes I used the word "feel" here and it it a weak argument to be sure

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Salz, Rich via openssl-users]

>  So the CHANGES file isn't really "changes".

The full list of everything that has changed can be found via git logs.  As 
Matt said, we only put particularly significant items in the CHANGES file.


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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Dennis Clarke]

On 06/01/2017 06:42 AM, Matt Caswell wrote:



On 25/05/17 15:29, Dennis Clarke wrote:


So this is exclusively a change to support mingw64 ?


Sorry, I missed this email somehow. This release rolls up numerous bug
fixes that have been implemented since the last release. We only put
particularly significant items in CHANGES.




One of the curious things I do ( there are numerous it seems ) is to
sometimes run a "catalog" process on a source tree where I get the file
list and the sha256 hash of every file.  Then compare with the previous
release.  There are a lot of differences.  A lot.  I can then "diff" for
my own reasons of curiosity.

So the CHANGES file isn't really "changes".

Dennis Clarke

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

Re: [openssl-users] Making a CRL with an authority key identifier

[Ivan Rubinson]

Yep, that solved it. Thank you very much.

On Thu, Jun 1, 2017 at 1:31 PM, Ivan Rubinson  wrote:

> Aha, I can't believe I missed that.
> That's why an extra pair of fresh eyes is helpful.
> Thank you Juan. I'll test this now.
>
> On Thu, Jun 1, 2017 at 1:22 PM, Juan Angel Martin (AC Camerfirma) <
> martin...@camerfirma.com> wrote:
>
>> Hi,
>>
>>
>>
>> Uncomment line 54
>>
>> crl_extensions= crl_ext
>>
>>
>>
>> BR
>>
>> Juan Ángel
>>
>>
>>
>> *De:* openssl-users [mailto:openssl-users-boun...@openssl.org] *En
>> nombre de *Ivan Rubinson
>> *Enviado el:* jueves, 1 de junio de 2017 12:15
>> *Para:* openssl-users@openssl.org
>> *Asunto:* [openssl-users] Making a CRL with an authority key identifier
>>
>>
>>
>> Hello,
>>
>> My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an
>> authority key identifier.
>>
>> (a third party API expects it from the CRL)
>>
>> I make my own CA, use it to sign a certificate, and then generate the
>> CRL. This is the configuration file: https://pastebin.com/yL4UBtGW (it's
>> basically the example configuration file with a few changes).
>>
>> Here are the commands I run:
>>
>> Making the CA:
>>
>> openssl req -new -x509 -days 3650 -extensions v3_ca -keyout
>> private/cakey.pem -out cacert.pem -config req.cnf
>>
>> Making the certificate:
>>
>> openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem
>> -config req.cnf
>> openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem
>>
>> Making the CRL:
>>
>> openssl ca -config req.cnf -gencrl -out crl.pem
>>
>>
>>
>> I'm using OpenSSL-Win64 0.9.8g
>>
>> Even though on line 251 I ask OpenSSL to have an authority key
>> identifier, the generated CRL doesn't have it. I've searched on google and
>> tried multiple things (like uncommenting issuerAltName, or giving it
>> different options) and the CRL still doesn't have it.
>>
>> At this point I'm stumped, and I'd like to ask you nice people for help.
>>
>> Thank you in advance,
>>
>> Ivan Rubinson
>>
>>
>>
>>
>> 
>>
>> Virus-free. www.avast.com
>> 
>>
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Dennis Clarke]

On 06/01/2017 09:53 AM, Salz, Rich via openssl-users wrote:

  So the CHANGES file isn't really "changes".


The full list of everything that has changed can be found via git logs.  As 
Matt said, we only put particularly significant items in the CHANGES file.




Why?

Why isn't the list of changes dumped into a simple text file and
included in the source release tarball ?   Consider users and systems
which do not have git installed by default.  For that matter, git does
not exist or even compile on those target systems but openssl most
certainly does.


Dennis

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Matt Caswell]

On 01/06/17 15:32, Dennis Clarke wrote:
> 
>> They are easily obtainable even if you do not have git. The list for
>> 1.0.2l is here:
>>
>> https://github.com/openssl/openssl/commits/OpenSSL_1_0_2l
> 
> ( point missed )
> 
> The issue is that the CHANGES file simply isn't.  The most recent for
> 1.0.2l being truely spartan. If this were vim or perhaps nano or even
> grep then I would go digging. However in these times of ever more
> security concerns for our servers I feel[1] that the openssl source
> release should at least have a trivial text list with more data than this :

CHANGES is what it is - a list of changes we thought were particularly
worthy of note. If that's not enough information for you then use the
git logs. I see very little value in automatically extracting info out
of the logs and including it in the distribution when the logs are so
easily accessible elsewhere.

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