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 possi
> 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
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 po
> 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
> 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 t
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.
Ye
> 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
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,
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 dist
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
14036901
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 unsubscrib
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
>
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
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 f
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
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 l
> 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/opens
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) <
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 s
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
>
> Th
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
>
>
>
> B
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
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
basicall
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 w
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_SCS
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: Frid
26 matches
Mail list logo
