Matt Caswell 于2018年9月12日周三 下午4:16写道：
>
>
> On 12/09/18 08:07, John Jiang wrote:
> > I just build OpenSSL 1.1.1 on MacOSX.
> > Tried 0-RTT, and the commands like the followings,
> > openssl s_server -cert server.cer -key server.key -tls1_3 -early_data
> > -accept 9443
> > ...
> > openssl s_client
On 12/09/18 09:34, John Jiang wrote:
>
> It looks the session was resumed, but early data still was rejected.
Hmm. Strange. I just tried the exact same sequence of commands and it
was accepted.
One thing to try is to recompile OpenSSL with the "enable-ssl-trace"
config option. Then you can
I just build OpenSSL 1.1.1 on MacOSX.
Tried 0-RTT, and the commands like the followings,
openssl s_server -cert server.cer -key server.key -tls1_3 -early_data
-accept 9443
...
openssl s_client -CAfile ca.cer -tls1_3 -sess_in openssl.sess -early_data
data -connect localhost:9443
s_client reported
Hello,
The issue https://github.com/openssl/openssl/pull/7129 has introduced a
possibility to limit the amount of TLS records processed without key
changing as required by FIPS.
We in Russia have limitations with the same semantics applicable to Russian
GOST TLS ciphersuites (
On 12/09/18 16:23, Thomas J. Hruska wrote:
> On 9/12/2018 7:03 AM, Viktor Dukhovni wrote:
>>
>>
>>> On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska
>>> wrote:
>>>
>>> Casting to time_t appears to correct the issue and the build
>>> completes successfully:
>>>
>>> const time_t default_time =
On 09/12/2018 10:44 AM, Viktor Dukhovni wrote:
On Sep 12, 2018, at 10:41 AM, Viktor Dukhovni
wrote:
IIUC, only Firefox nightly as of approximately today will support the final
RFC 8446 version; I haven't looked into Chrome yet.
From the Firefox TLS 1.3 blog entry:
> Some Chrome browsers seem to be hitting https://www.tls13.net/
> with versions from Chrome/70.0.3534.4 upwards to Chrome/71.0.3544.0
Some of my public web servers are now on yesterday's version, three
TLSv1.3 users today, two with Firefox 63, one with
Chrome/68.0.3440.106+Safari/537.36.
I
> On Sep 12, 2018, at 11:24 AM, Matt Caswell wrote:
>
>
> Is this new to 1.1.1? Or does it also impact 1.1.0?
Seems to affect 1.1.0 also:
$ git grep -A1 CT_POLICY_EVAL_CTX_get_time OpenSSL_1_1_0-stable -- test
OpenSSL_1_1_0-stable:test/ct_test.c:const time_t default_time =
On 09/12/2018 09:50 AM, Klaus Keppler wrote:
Hi,
when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
1.1.1-release), Firefox/Chrome can't access it.
Be sure to use Firefox nightly version 64.0a1 and upwards. Anything less
and you may be getting draft 28 support and NOT
In message on Wed, 12 Sep
2018 16:24:03 +0100, Matt Caswell said:
>
>
> On 12/09/18 16:23, Thomas J. Hruska wrote:
> > On 9/12/2018 7:03 AM, Viktor Dukhovni wrote:
> >>
> >>
> >>> On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska
> >>> wrote:
> >>>
> >>> Casting to time_t appears to correct the
> IIUC, only Firefox nightly as of approximately today will support
> the final RFC 8446 version;
Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday.
https://download.mozilla.org/?product=firefox-beta-stub=win=en-U
S
> I haven't looked into Chrome yet.
My versions don't work
On 09/12/2018 12:06 PM, Angus Robertson - Magenta Systems Ltd wrote:
IIUC, only Firefox nightly as of approximately today will support
the final RFC 8446 version;
Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday.
Even Firefox/60.0 works.
On 9/12/2018 7:03 AM, Viktor Dukhovni wrote:
On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska
wrote:
Casting to time_t appears to correct the issue and the build completes
successfully:
const time_t default_time =
(time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) /
I’m an OpenSSL newbie and this is my first post. I’m using OpenSSL for receipt
validation in an iOS application.
Is there a list of checksums to verify openssl download versions? I believe I
should be using openssl-1.0.2p. Can openssl-1.1.1 be used in a production
application yet? Why
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Matt Caswell
> Sent: Wednesday, September 12, 2018 14:29
>
> On 12/09/18 19:24, Chris Outwin wrote:
> > I’m an OpenSSL newbie and this is my first post. I’m using OpenSSL for
> receipt validation in an iOS application.
Thank you very much for your helpful reply.
I’m a graphics programmer with no experience in PGP. The shell script I have
calls:
OPENSSL_ARCHIVE_URL="https://www.openssl.org/source/old/${BRANCH}/${OPENSSL_ARCHIVE_FILE_NAME}”
in the process of downloading OpenSSL for use in building an iOS
On 12/09/18 19:24, Chris Outwin wrote:
> I’m an OpenSSL newbie and this is my first post. I’m using OpenSSL for
> receipt validation in an iOS application.
>
> Is there a list of checksums to verify openssl download versions?
Next to each download on the website there are links for
As I understand and check:
https://www.tls13.net accept connexion from final openssl-1.1.1 (RFC8446)
but not from openssl-1.1.1 pre8 (draft 28)
https://tls13.crypto.mozilla.org accept connexion from openssl-1.1.1 pre8
(draft 28) but not from final openssl-1.1.1 (RFC8446)
(Top posting to avoid zig-zag)
Testing your OpenSSL download with the HTTPS security bites its
own tail, especially if your download tool uses an (older) version
of OpenSSL to check the connection.
But unless you have an established personal list of GPG/PGP keys
you have checked against their
In FIPS mode, the default entropy gathering is not performed. You, the user,
must supply all entropy to the module.
See section 6.1.1 of the OpenSSL FIPS User Guide
(https://www.openssl.org/docs/fips/UserGuide-2.0.pdf).
Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security &
I wasn’t aware of other national standards requiring a similar check.
I made the change in the AES-GCM code because FIPS demands the check be inside
the FIPS boundary. I’d have preferred to make it in the TLS layer, but that
mustn’t be inside the FIPS boundary. My understanding is that TLS
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Wednesday, September 12, 2018 17:18
>
> Testing your OpenSSL download with the HTTPS security bites its
> own tail, especially if your download tool uses an (older) version
> of OpenSSL to check the
On 09/12/2018 04:46 PM, Juan Isoza wrote:
As I understand and check:
https://www.tls13.net accept connexion from final openssl-1.1.1
(RFC8446) but not from openssl-1.1.1 pre8 (draft 28)
At this point the protocol is published and the OpenSSL 1.1.1 release is
done. You should not be
On 12/09/18 08:07, John Jiang wrote:
> I just build OpenSSL 1.1.1 on MacOSX.
> Tried 0-RTT, and the commands like the followings,
> openssl s_server -cert server.cer -key server.key -tls1_3 -early_data
> -accept 9443
> ...
> openssl s_client -CAfile ca.cer -tls1_3 -sess_in openssl.sess
>
Nothing particularly unexpected in there. Could you send me the s_server
log including *both* connections, i.e. the original connection attempt
to create the session, followed by the subsequent resume.
Thanks
Matt
On 12/09/18 11:50, John Jiang wrote:
> Could you please take a look at the
Very strange. I re-tried the same case, but the resumption failed.
The attached logs contain the full outputs in the both connections on
server and client sides.
On Wed, Sep 12, 2018 at 7:09 PM Matt Caswell wrote:
> Nothing particularly unexpected in there. Could you send me the s_server
> log
Were you using the -www option to s_server before? You didn't mention it
in your original email, but in this log it shows you using it.
Try without that option.
Matt
On 12/09/18 12:25, John Jiang wrote:
> Very strange. I re-tried the same case, but the resumption failed.
> The attached logs
cl /Z7 /Fdapp.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /WX
/I "include" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE"
-D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE"
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG"
-D_USE_32BIT_TIME_T
> On Sep 12, 2018, at 10:41 AM, Viktor Dukhovni
> wrote:
>
>> IIUC, only Firefox nightly as of approximately today will support the final
>> RFC 8446 version; I haven't looked into Chrome yet.
>
> From the Firefox TLS 1.3 blog entry:
>
>
> On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska
> wrote:
>
> Casting to time_t appears to correct the issue and the build completes
> successfully:
>
>const time_t default_time =
> (time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) /
>1000;
Since the
Hi,
when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
1.1.1-release), Firefox/Chrome can't access it.
According to all docs I've read so far, the TLS 1.3 implementations both
from Firefox (62.x) and from Chrome (69.x) should be compatible so far.
I created the web server with
On Wed, Sep 12, 2018 at 03:50:17PM +0200, Klaus Keppler wrote:
> Hi,
>
> when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
> 1.1.1-release), Firefox/Chrome can't access it.
> According to all docs I've read so far, the TLS 1.3 implementations both
> from Firefox (62.x) and
> On Sep 12, 2018, at 10:20 AM, Benjamin Kaduk via openssl-users
> wrote:
>
> IIUC, only Firefox nightly as of approximately today will support the final
> RFC 8446 version; I haven't looked into Chrome yet.
From the Firefox TLS 1.3 blog entry:
On 12/09/18 14:04, John Jiang wrote:
> I got the points!
> 1. should not use -www option on server side
Right - we should probably error out if you attempt to use those two
options in combination.
> 2. Possibly, no session ticket was saved in the first connection with
> the below command,
>
I got the points!
1. should not use -www option on server side
2. Possibly, no session ticket was saved in the first connection with the
below command,
echo "M" | openssl s_client -trace -state -CAfile ca.cer -tls1_3 -sess_out
openssl.sess -connect localhost:9443
The client exited so quickly that
Could you please take a look at the attached s_client.log?
It was outputted by s_client with options -trace and -state in the second
connection.
Matt Caswell 于2018年9月12日周三 下午4:48写道：
>
>
> On 12/09/18 09:34, John Jiang wrote:
> >
> > It looks the session was resumed, but early data still was
Hello,
We have a custom hardware system running Linux Debian OS having openssl
1.0.2l compiled with FIPS module 2.0. We are trying for FIPS 140-2
certification.
By default it looks like openssl RAND_poll() uses /dev/urandom for entropy.
We are told this may not be acceptable for FIPS 140-2 Level
37 matches
Mail list logo
