Ah, yes. Well that's why FIPS for OpenSSL is the main focus of the
next release, and presumably why Oracle is one of the sponsors... :-)
In the mean-time, yeah, you may have to support 1.0.2 for ~1 more year.
> On Sep 12, 2018, at 1:18 AM, Jordan Brown
> wrote:
>
> My understanding is that
> On Sep 11, 2018, at 9:57 PM, Jakob Bohm wrote:
>
> Clarification question, as I cannot match what you wrote above with
> the changelog (NEWS) in the OpenSSL 1.1.1 tarball:
>
> - Does OpenSSL 1.1.1 include SSL3.0 support or not?
The code is there, but it is disabled in default builds. You
On 11/09/2018 19:34, Viktor Dukhovni wrote:
On Sep 11, 2018, at 1:17 PM, Jordan Brown wrote:
The key piece that I was missing - I hadn't looked at and thought about the protocol
enough - was that there's no version-independent way for the server to fail. If the
server supports only
> On Sep 11, 2018, at 1:17 PM, Jordan Brown
> wrote:
>
> The key piece that I was missing - I hadn't looked at and thought about the
> protocol enough - was that there's no version-independent way for the server
> to fail. If the server supports only versions larger than the client
>
On 9/11/2018 9:46 AM, Viktor Dukhovni wrote:
> Part of the confusion is also using a version inflexible method on the
> client, that's rarely done.
My test engineers like trying all the variations, including the ones
nobody will ever use :-)
> Instead of "s_client -tls1" it is wiser to test with
> On Sep 11, 2018, at 12:33 PM, Jordan Brown
> wrote:
>
> Thanks!
>
> Now I need to wrap my head around what that all means.
>
> It sounds like the protocol doesn't really have a version-independent way for
> the version negotiation to cleanly fail. That's unfortunate.
Well, once SSL3
Thanks!
Now I need to wrap my head around what that all means.
It sounds like the protocol doesn't really have a version-independent
way for the version negotiation to cleanly fail. That's unfortunate.
--
openssl-users mailing list
To unsubscribe:
> On Aug 31, 2018, at 9:14 PM, Jordan Brown
> wrote:
>
> We're trying to nail down error reporting for TLS version mismatches, and
> we're seeing a couple of puzzling behaviors.
>
> First, and most puzzling... assume these two command lines:
>
> $ openssl s_server -cert 2018.08.31.a.pem
And of course I remember just after hitting Send: Thanks!
--
Jordan Brown, Oracle Solaris
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
On 9/10/2018 1:42 PM, Kurt Roeckx wrote:
> I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I believe
> this was fixed in all branches. I've tried 1.0.2o too, and I still get
> the alert back.
Interesting. My attempts were on Solaris x86[*]. I'll have to try
other platforms.
On Fri, Aug 31, 2018 at 06:14:25PM -0700, Jordan Brown wrote:
> We're trying to nail down error reporting for TLS version mismatches,
> and we're seeing a couple of puzzling behaviors.
>
> First, and most puzzling... assume these two command lines:
>
> $ openssl s_server -cert
Any thoughts here?
On 8/31/2018 6:14 PM, Jordan Brown wrote:
>
> We're trying to nail down error reporting for TLS version mismatches,
> and we're seeing a couple of puzzling behaviors.
>
> First, and most puzzling... assume these two command lines:
>
> $ openssl s_server -cert
We're trying to nail down error reporting for TLS version mismatches,
and we're seeing a couple of puzzling behaviors.
First, and most puzzling... assume these two command lines:
$ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1
$ openssl s_client -connect
13 matches
Mail list logo
