SM3WithSM2 Certificate

[John Jiang]

Hi,
Using OpenSSL 1.1.1i.

I suppose OpenSSL already supports SM algorithms, including SM2 and SM3.
However, I used the following command on a SM2 certificate,
openssl x509 -text -in test-sm2.crt

and got the below line,
Signature Algorithm: 1.2.156.10197.1.501

This OID is actually SM2 signing with SM3.
Why doesn't openssl x509 tool display this name?
Does OpenSSL support this signature scheme?

Best regards,
John Jiang

Re: OCSP response signature algorithm

[John Jiang]

I just got the OpenSSL ocsp tool option -rmd for specifying the digest
algorithm in signature.

This option is described at the below page,
https://www.openssl.org/docs/manmaster/man1/openssl-ocsp.html

Just out of curiosity, why isn't it at the following man page?
https://www.openssl.org/docs/man1.1.1/man1/ocsp.html
Though this option is supported by 1.1.1 series.

On Mon, Jul 6, 2020 at 6:15 AM John Jiang  wrote:

> I just want to know how does OpenSSL implement RFC 6960 section 4.4.7.2
> Responder Signature Algorithm Selection.
>
> Could I take a OpenSSL responder to use SHA1withRSA signature algorithm
> if the certificate is signed by this algorithm?
>
> [1] https://tools.ietf.org/html/rfc6960#section-4.4.7.2
>
> On Sat, Jul 4, 2020 at 12:18 AM John Jiang 
> wrote:
>
>> Hi,
>> I'm using OpenSSL 1.1.1.
>>
>> Can I configure the OCSP response signature algorithm?
>> For a RSA issuer, it looks SHA256withRSA always be selected.
>>
>> PreferredSignatureAlgorithms extension in OCSP request may affect this
>> algorithm in OpenSSL OCSP response. However, I prefer to use configuration.
>>
>> Thanks!
>>
>

Re: OCSP response signature algorithm

[John Jiang]

I just want to know how does OpenSSL implement RFC 6960 section 4.4.7.2
Responder Signature Algorithm Selection.

Could I take a OpenSSL responder to use SHA1withRSA signature algorithm
if the certificate is signed by this algorithm?

[1] https://tools.ietf.org/html/rfc6960#section-4.4.7.2

On Sat, Jul 4, 2020 at 12:18 AM John Jiang  wrote:

> Hi,
> I'm using OpenSSL 1.1.1.
>
> Can I configure the OCSP response signature algorithm?
> For a RSA issuer, it looks SHA256withRSA always be selected.
>
> PreferredSignatureAlgorithms extension in OCSP request may affect this
> algorithm in OpenSSL OCSP response. However, I prefer to use configuration.
>
> Thanks!
>

OCSP response signature algorithm

[John Jiang]

Hi,
I'm using OpenSSL 1.1.1.

Can I configure the OCSP response signature algorithm?
For a RSA issuer, it looks SHA256withRSA always be selected.

PreferredSignatureAlgorithms extension in OCSP request may affect this
algorithm in OpenSSL OCSP response. However, I prefer to use configuration.

Thanks!

Specify multiple certs for s_server and s_client

[John Jiang]

Hi,
Can I specify multiple certificates for tools s_server and s_client?
I need to check the certificate selection with certificate_authorities.

And it looks s_server has no option for certificate_authorities, however
s_client has -requestCAfile for that extension.

Best regards,
John

Re: Support FFDHE?

[John Jiang]

On Thu, Feb 27, 2020 at 9:27 PM Salz, Rich  wrote:

>
>- Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
>
>
>
> TLS 1.3 doesn’t have those groups.
>
Per section Supported Groups in RFC 8446 [1], FFDHE groups could be
supported.
enum {

/* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E),

/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),

/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
(0x)
} NamedGroup;

[1] https://tools.ietf.org/html/rfc8446#section-4.2.7

>

Re: Support FFDHE?

[John Jiang]

I would have highlighted that OpenSSL 1.1.1d was being used in my testing.

On Thu, Feb 27, 2020 at 5:13 PM John Jiang  wrote:

> Hi,
> It sounds FFDHE groups are already supported [1]
> But the tools, like s_client, also support them.
> Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
> it just raised the issue: Error with command: "-groups ffdhe2048"
> If using P-256 or X25519, it worked fine.
>
> I also tried option "-groups FFDHE2048". The same error raised again.
>
> [1] https://github.com/openssl/openssl/pull/8178
>

Support FFDHE?

[John Jiang]

Hi,
It sounds FFDHE groups are already supported [1]
But the tools, like s_client, also support them.
Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
it just raised the issue: Error with command: "-groups ffdhe2048"
If using P-256 or X25519, it worked fine.

I also tried option "-groups FFDHE2048". The same error raised again.

[1] https://github.com/openssl/openssl/pull/8178

Re: Are DHE_DSS cipher suites not supported?

[John Jiang]

On Fri, Oct 25, 2019 at 8:50 PM Matt Caswell  wrote:

>
>
> On 25/10/2019 09:39, Viktor Dukhovni wrote:
> > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote:
> >
> >> I'm using OpenSSL 1.1.1d.
> >> Just want to confirm if DHE_DSS cipher suites are not supported by this
> >> version.
> >
> > They are supported, but:
> >
> > * DSS ciphersuites are disabled by DEFAULT.  You need to
> >   specify an explicit "-cipher" option to enable these,
> >   for example:
> >
> > $ openssl s_server -accept 12345 \
> >   -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \
> >   -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem
> >
> >   or more typically:
> >
> >   -cipher 'ALL:!RC4:!aNULL'
> >
> > * You should also supply DH parameters as above:
>
> This step is optional. It will work just fine with default parameters if
> you don't specify them.
>
I only add option -cipher to s_server. That works for me.
Thanks!


>
> Matt
>
>
>
> >
> >   -dhparam dhparam.pem
> >
> >   I generated these with:
> >
> >   $ openssl genpkey -genparam -algorithm dh \
> >   -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem
> >
>

Are DHE_DSS cipher suites not supported?

[John Jiang]

Hi,
I'm using OpenSSL 1.1.1d.
Just want to confirm if DHE_DSS cipher suites are not supported by this
version.

Please consider the below simple case,
1. s_server uses a DSA certifcate
2. force s_client to use TLS 1.2 and TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
(DHE-DSS-AES256-GCM-SHA384)
the connection failed, and s_server reported: no shared
cipher:ssl/statem/statem_srvr.c:2259

But I still can see this cipher suite in the below doc,
https://www.openssl.org/docs/man1.1.1/man1/ciphers.html

Re: Enabled weak cipher suites

[John Jiang]

On Wed, Jun 26, 2019 at 2:59 PM Dr Paul Dale  wrote:

> Yes there is but it will require a reconfigure and a recompile.
>
Could you please show me more details about it?
Which option(s) should be used for configuring and compiling?


>
> The big question is: "why?”
> RC4 and MD5 are both considered broken.
>
Don't worry, just for some testing.

Thanks!


>
> Pauli
> --
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
> On 26 Jun 2019, at 11:41 am, John Jiang  wrote:
>
> Hi,
> I'm using s_server and s_client from OpenSSL 1.1.1.
> It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are
> disabled.
> Is there any way to re-enable these cipher suites?
>
> Thanks!
>
>
>

Enabled weak cipher suites

[John Jiang]

Hi,
I'm using s_server and s_client from OpenSSL 1.1.1.
It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are
disabled.
Is there any way to re-enable these cipher suites?

Thanks!

Re: Is X25519/X448 supported for TLSv1.2?

[John Jiang]

On Thu, Jun 13, 2019 at 12:28 PM Viktor Dukhovni 
wrote:

> On Thu, Jun 13, 2019 at 10:49:14AM +0800, John Jiang wrote:
>
> > I got the point: the server certificate is ECDSA with curve secp256r1.
> > It works with RSA certificate and curves
> > sepc256r1/sepc384r1/sepc521r1/x25519/x448.
>
> See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924
>
> When using ECDSA with TLSv1.2, the group list MUST include the group
> used in the certificate.  Otherwise, you get no shared cipher as
> you reported.

How about this point in TLSv1.3?
With my testing, the case "ECDSA certificate with curve secp256r1 + named
group secp521r1" work fine with OpenSSL s_server and s_client.


> You can *prefer* X25519, but you cannot only offer
> X25519.
>
Just an intentional test.

Re: Is X25519/X448 supported for TLSv1.2?

[John Jiang]

I got the point: the server certificate is ECDSA with curve secp256r1.
It works with RSA certificate and curves
sepc256r1/sepc384r1/sepc521r1/x25519/x448.

On Thu, Jun 13, 2019 at 3:00 AM Viktor Dukhovni 
wrote:

> On Wed, Jun 12, 2019 at 05:31:30PM +0800, John Jiang wrote:
>
> > > > Tried below commands,
> > > > openssl s_server -trace -state -cert server.cer -key server.key
> -accept port
> > > > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519
> -connect localhost:port
> > >
> > > With same commands, using OpenSSL 1.1.1c, I get:
> > >
> > > CONNECTION ESTABLISHED
> > > Protocol version: TLSv1.2
> > > Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
> > > Peer certificate:
> > > Hash used: SHA256
> > > Signature type: RSA-PSS
> > > Supported Elliptic Curve Point Formats: ...
> > > Server Temp Key: X25519, 253 bits
> > >
> > > Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> > > linked against 1.1.0 libraries...
> > >
> > My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
> > version.
>
> You say that, but the evidence suggests otherwise.  In each of
> whatever shells you're using to start the client and server,
> it would be prudent to run:
>
> $ openssl version -v
>
> Here's an example with the command and library at the same version:
>
> $ /usr/local/bin/openssl version -v
> OpenSSL 1.1.1c  28 May 2019
>
> And here's another where they differ in the patchlevel:
>
> $ LD_PRELOAD=/lib/libcrypto.so.111:/usr/lib/libssl.so.111
> /usr/local/bin/openssl version -v
> OpenSSL 1.1.1c  28 May 2019 (Library: OpenSSL 1.1.1a-freebsd  20 Nov
> 2018)
>
> Without forcing anything with LD_PRELOAD, ... are your client and
> server in fact 1.1.1 in both the executable and the library?
>
> --
> Viktor.
>

Re: Is X25519/X448 supported for TLSv1.2?

[John Jiang]

On Wed, Jun 12, 2019 at 4:34 PM Viktor Dukhovni 
wrote:

> On Wed, Jun 12, 2019 at 03:45:12PM +0800, John Jiang wrote:
>
> > Using OpenSSL 1.1.1.
> > Just want to confirm that if OpenSSL supports curves X25519 and X448 for
> > TLSv1.2.
>
> Yes, it does.
>
> > Tried below commands,
> > openssl s_server -trace -state -cert server.cer -key server.key -accept
> port
> > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519
> -connect localhost:port
>
> With same commands, using OpenSSL 1.1.1c, I get:
>
> CONNECTION ESTABLISHED
> Protocol version: TLSv1.2
> Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
> Peer certificate:
> Hash used: SHA256
> Signature type: RSA-PSS
> Supported Elliptic Curve Point Formats:
> uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
> Server Temp Key: X25519, 253 bits
>
> Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> linked against 1.1.0 libraries...
>
My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
version.

Is X25519/X448 supported for TLSv1.2?

[John Jiang]

Hi,
Using OpenSSL 1.1.1.
Just want to confirm that if OpenSSL supports curves X25519 and X448 for
TLSv1.2.

Tried below commands,
openssl s_server -trace -state -cert server.cer -key server.key -accept port
openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519
-connect localhost:port

the server side raised the below error,
140735913575296:error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared
cipher:ssl/statem/statem_srvr.c:2253:

If using -groups P-256, the handshaking was fine.

Session ID or Session ticket?

[John Jiang]

Hi,
I'm using OpenSSL 1.1.1

I just use the below s_client command to test resumption.
openssl s_client -CAfile CA.cer -tls1_2 -sess_in openssl.sess -connect
localhost:9443

Is there any option to take this tool to use only session id or session
ticket for resumption?

Thanks!

Re: s_server/s_client on checking middlebox compatibility

[John Jiang]

I had tried TLS Fuzzer, and it worked for me.
I just wished that OpenSSL can do the similar things.

Thanks!

On Tue, Feb 26, 2019 at 9:56 PM Hubert Kario  wrote:

> On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> > Is it possible to check if peer implements middlebox compatibility by
> > s_server/s_client?
> > It looks the test tools don't care this point.
> > For example, if a server doesn't send change_cipher_spec after
> > HelloRetryRequest, s_client still feels fine.That's not bad. But can I
> > setup these tools to check middlebox compatibility?
>
> As Matt said, there's no human-readable output that shows that.
>
> tlsfuzzer does verify if the server sends ChangeCipherSpec and at what
> point in the connection (all scripts expect it right after ServerHello or
> right after HelloRetryRequest depending on connection).
>
> You can use
>
> https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-conversation.py
> https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-hrr.py
> and
>
> https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-session-resumption.py
> respectively to test regular handshake, one with HelloRetryRequest
> and one that performs session resumption.
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

s_server/s_client on checking middlebox compatibility

[John Jiang]

Is it possible to check if peer implements middlebox compatibility by
s_server/s_client?
It looks the test tools don't care this point.
For example, if a server doesn't send change_cipher_spec after
HelloRetryRequest, s_client still feels fine.That's not bad. But can I
setup these tools to check middlebox compatibility?

Re: [openssl-users] Two sessions in a single full handshake

[John Jiang]

Now that full handshake sends two sessions, does that mean option -sess_out
saves both of the sessions to a local file?
If so, when resume session via option -sess_in, which session will be
resumed?

On Sun, Sep 30, 2018 at 11:47 AM Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:

> s_client has -sess_out and -sess_in options that can be used
> to save session information to a file and read it in for a subsequent
> connection.  Neither is used by default.
>
> -Ben
>
> On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote:
> > Does s_client resume any session in the local session file?
> >
> > On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users <
> > openssl-users@openssl.org> wrote:
> >
> > >
> > >- The debug logs display two "SSL-Session" blocks in a full
> handshake.
> > >
> > > Only one "SSL-Session" block is displayed in a resumption.
> > >
> > > Why does full handshake has two sessions?
> > >
> > >
> > >
> > > This is part of the TLS 1.3 standard.  A server can send back multiple
> > > sessions, so that a client may resume with a different session, and
> > > therefore prevent an observer from “linking” two different activities.
> > > --
> > > 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 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] Two sessions in a single full handshake

[John Jiang]

Does s_client resume any session in the local session file?

On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

>
>- The debug logs display two "SSL-Session" blocks in a full handshake.
>
> Only one "SSL-Session" block is displayed in a resumption.
>
> Why does full handshake has two sessions?
>
>
>
> This is part of the TLS 1.3 standard.  A server can send back multiple
> sessions, so that a client may resume with a different session, and
> therefore prevent an observer from “linking” two different activities.
> --
> 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] Two sessions in a single full handshake

[John Jiang]

Using OpenSSL 1.1.1.
The debug logs display two "SSL-Session" blocks in a full handshake.
Only one "SSL-Session" block is displayed in a resumption.
Why does full handshake has two sessions?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why was early data rejected?

[John Jiang]

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 didn't receive sever's session ticket.

On Wed, Sep 12, 2018 at 8:16 PM Matt Caswell  wrote:

> 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 contain the full outputs in the both connections on
> > server and client sides.
> >
> > On Wed, Sep 12, 2018 at 7:09 PM Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> > 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 attached s_client.log?
> > > It was outputted by s_client with options -trace and -state in the
> > > second connection.
> > >
> > > Matt Caswell mailto:m...@openssl.org>
> > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> 于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
> > 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 add the "-trace" option to
> > s_client and/or
> > > s_server which might give a better clue as to why it is
> rejected.
> > >
> > > 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
> >
> >
> >
> --
> 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] Why was early data rejected?

[John Jiang]

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 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 attached s_client.log?
> > It was outputted by s_client with options -trace and -state in the
> > second connection.
> >
> > Matt Caswell mailto:m...@openssl.org>> 于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
> 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 add the "-trace" option to s_client
> and/or
> > s_server which might give a better clue as to why it is rejected.
> >
> > 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
>


s_server.log
Description: Binary data


s_client.log
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why was early data rejected?

[John Jiang]

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 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 add the "-trace" option to s_client and/or
> s_server which might give a better clue as to why it is rejected.
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


s_client.log
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why was early data rejected?

[John Jiang]

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 -CAfile ca.cer -tls1_3 -sess_in openssl.sess
> > -early_data data -connect localhost:9443
> >
> > s_client reported
> > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
>
> The "New" here means that the resumption attempt failed. Successful
> resumption is a pre-requisite for early data. How did you create
> "openssl.sess"?
>
openssl s_client -CAfile ca.cer -tls1_3 -sess_out openssl.sess -connect
localhost:9443

I just re-tried my test case.
Re-started s_server and did two connection. The second connection reported:
Reused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was rejected
Verify return code: 0 (ok)

It looks the session was resumed, but early data still was rejected.


> Matt
>
>
> > ...
> > Early data was rejected
> > Verify return code: 0 (ok)
> >
> > What's wrong with my testing?
> >
> >
> --
> 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] Why was early data rejected?

[John Jiang]

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
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
...
Early data was rejected
Verify return code: 0 (ok)

What's wrong with my testing?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

2018-06-20 17:01 GMT+08:00 Matt Caswell :

>
>
> On 20/06/18 07:11, John Jiang wrote:
> > 2018-06-19 6:21 GMT+08:00 Matt Caswell  > <mailto:m...@openssl.org>>:
> >
> >
> >
> > On 18/06/18 21:23, Hubert Kario wrote:
> > > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:
> > >> On 08/06/18 02:48, John Jiang wrote:
> > >>> Is it possible to check Key/IV update feature via these tools?
> > >>> Thanks!
> > >>
> > >> Yes. See the "CONNECTED COMMANDS" sections of these pages:
> > >> https://www.openssl.org/docs/manmaster/man1/s_server.html
> > <https://www.openssl.org/docs/manmaster/man1/s_server.html>
> > >> https://www.openssl.org/docs/manmaster/man1/s_client.html
> > <https://www.openssl.org/docs/manmaster/man1/s_client.html>
> > >>
> > >> Basically typing "k" or "K" from an s_server/s_client session
> will issue
> > >> a KeyUpdate message. Using the capitalised form ("K"),
> additionally
> > >> requests a KeyUpdate from the peer.
> > >
> > > Are there similar commands to perform or control post-handshake
> client
> > > authentication?
> >
> > Yes. As mentioned on the above s_server link, type "c" from an
> s_server
> > session to send a certificate request to the client.
> >
> > With the mentioned pages, I don't get how to test 0-RTT.
> > But it sounds that OpenSSL already supports this feature.
>
> It is on those pages - just not in the "CONNECTED COMMANDS" section.
>
> To test 0-RTT early data start s_server with the "-early_data" flag:
>
> $ openssl s_server -early_data
>
> Obtain a session that can later be used for sending early data:
>
> $ openssl s_client -sess_out session.pem
>
> Type "Q" in the s_client window to close the connection. Now you can do
> a 0-RTT handshake and send early data (assuming the existence of a file
> "myearlydata.dat" containing the early data you want to send):
>
> $ openssl s_client -sess_in session.pem -early_data myearlydata.dat
>
> If s_server doesn't use option -early_data, the NewSessionTicket won't
contain early_data extension,
and then in the second connection, s_client won't send early data even
option -early_data is used.
Right?
Is it possible to take s_client to send early data, even though the server
don't support 0-RTT.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

2018-06-19 6:21 GMT+08:00 Matt Caswell :

>
>
> On 18/06/18 21:23, Hubert Kario wrote:
> > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:
> >> On 08/06/18 02:48, John Jiang wrote:
> >>> Is it possible to check Key/IV update feature via these tools?
> >>> Thanks!
> >>
> >> Yes. See the "CONNECTED COMMANDS" sections of these pages:
> >> https://www.openssl.org/docs/manmaster/man1/s_server.html
> >> https://www.openssl.org/docs/manmaster/man1/s_client.html
> >>
> >> Basically typing "k" or "K" from an s_server/s_client session will issue
> >> a KeyUpdate message. Using the capitalised form ("K"), additionally
> >> requests a KeyUpdate from the peer.
> >
> > Are there similar commands to perform or control post-handshake client
> > authentication?
>
> Yes. As mentioned on the above s_server link, type "c" from an s_server
> session to send a certificate request to the client.
>
With the mentioned pages, I don't get how to test 0-RTT.
But it sounds that OpenSSL already supports this feature.

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

Re: [openssl-users] rsa_pss_pss_*/rsa_pss_rsae_* and TLS_RSA_*/TLS_ECDHE_RSA_*

[John Jiang]

2018-06-19 23:11 GMT+08:00 Jakob Bohm :

> On 19/06/2018 15:40, John Jiang wrote:
>
>> Using OpenSSL 1.1.1-pre7
>>
>> Please consider the following cases and handshaking results:
>> 1. rsa_pss_pss_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher
>> suite
>> Handshaking failed with no suitable cipher
>>
>> 2. rsa_pss_pss_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> cipher suite
>> Handshaking succeeded.
>>
>> 3. rsa_pss_rsae_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher
>> suite
>> Handshaking succeeded.
>>
>> 4. rsa_pss_rsae_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> cipher suite
>> Handshaking succeeded.
>>
>> Why did case 1 fail?
>>
> The TLS_RSA_ cipher suites require that the premaster secret
> is encrypted with the RSA key in the servers certificate.
> But an rsa_pss_pss_256 certificate (have not seen that notation
> before) is probably a signing-only certificate, that says not
> to encrypt anything with its RSA key.
>
Why does rsa_pss_rsae_256 + TLS_RSA_* work?
It sounds that rsa_pss_pss_256 and rsa_pss_rsae_256 are the same signature
scheme.

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

[openssl-users] rsa_pss_pss_*/rsa_pss_rsae_* and TLS_RSA_*/TLS_ECDHE_RSA_*

[John Jiang]

Using OpenSSL 1.1.1-pre7

Please consider the following cases and handshaking results:
1. rsa_pss_pss_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher
suite
Handshaking failed with no suitable cipher

2. rsa_pss_pss_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
cipher suite
Handshaking succeeded.

3. rsa_pss_rsae_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher
suite
Handshaking succeeded.

4. rsa_pss_rsae_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
cipher suite
Handshaking succeeded.

Why did case 1 fail?

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

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

Is it possible to check Key/IV update feature via these tools?
Thanks!

2018-05-23 20:33 GMT+08:00 Matt Caswell :

>
>
> On 23/05/18 12:39, John Jiang wrote:
> > Hi,
> > If just using s_server and s_client, can I test the TLS 1.3 features,
> > likes HelloRetryRequest and resumption?
>
> Yes.
>
> To create a normal (full handshake) TLSv1.3 connection just use
> s_server/s_client in the normal way, e.g.
>
> $ openssl s_server -cert cert.pem -key key.pem
> $ openssl s_client
>
> To test resumption first create a full handshake TLSv1.3 connection and
> save the session:
>
> $ openssl s_server -cert cert.pem -key key.pem
> $ openssl s_client -sess_out session.pem
>
> Close the s_client instance by entering "Q" followed by enter. Then
> (without closing the s_server instance) resume the session:
>
> $ openssl s_client -sess_in session.pem
>
>
> A HelloRetryRequest will occur if the key share provided by the client
> is not acceptable to the server. By default the client will send an
> X25519 key share, so if the server does not accept that group then an
> HRR will result, e.g.
>
> $ openssl s_server -cert cert.pem -key key.pem -groups P-256
> $ openssl s_client
>
>
> Of course a HelloRetryRequest all happens at the protocol layer and is
> invisible as far as a user of the command line apps is concerned. You
> will have to look at what happens "on the wire" to actually see it in
> action - for example by using wireshark. Alternatively you can compile
> OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
> to s_server or s_client to see what protocol messages are being exchanged.
>
> Matt
>
>
>
> >
> > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx  > <mailto:k...@roeckx.be>>:
> >
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
> > <https://wiki.openssl.org/index.php/TLS1.3>
> >
> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the latest beta release.
> >
> > When testing this, it's important that both sides of the
> > connection support the same TLS 1.3 draft version. OpenSSL
> > currently implements draft 26. We would like to see tests
> > for OpenSSL acting as client and server.
> >
> > https://github.com/tlswg/tls13-spec/wiki/Implementations
> > <https://github.com/tlswg/tls13-spec/wiki/Implementations> lists
> > other TLS 1.3 implementations and the draft they currently
> > support. Note that the versions listed there might not be for the
> > latest release. It also lists some https test servers.
> >
> > We would really like to see a diverse set of applictions being
> > tested. Please report any results you have to us.
> >
> >
> > Kurt
> >
> > --
> > openssl-users mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> > <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> --
> 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] Call for testing TLS 1.3

[John Jiang]

Hi Matt,
Thanks for your reply!

2018-05-23 20:33 GMT+08:00 Matt Caswell :

>
> To test resumption first create a full handshake TLSv1.3 connection and
> save the session:
>
> $ openssl s_server -cert cert.pem -key key.pem
> $ openssl s_client -sess_out session.pem
>
> Close the s_client instance by entering "Q" followed by enter. Then
> (without closing the s_server instance) resume the session:
>
> $ openssl s_client -sess_in session.pem
>
This way looks the same to test resumption on TLS 1.2.

The followings are some logs from my test.
The first connection:
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
B4A20A467729A8179ECE5912AD87A0E5A784B8573A6F98CB414498142A10A37593B10DE254197A98E05CE65BDD664776
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1527153377
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---

The second connection:
---
Reused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
601F249C2033D5E5DF23D3380E6A2D81B335AF420D59849BB2023C415D0553C5
Session-ID-ctx:
Master-Key:
68695BD547856C14E04C747CE884F876B1564DADC66F28CD24B95DF3240FE0C0F93F59ED650B5EE45F6D3EA40A71C993
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - 54 03 c8 0e e6 75 f3 ef-3f 7a 73 89 bc 87 69 ab
Tu..?zs...i.
0010 - cf e6 ff d1 f9 d8 24 36-0d e5 67 52 30 7c ea 0c
..$6..gR0|..
0020 - c8 a2 67 ad 24 f6 29 cc-2c 95 48 36 e8 87 f6 4e
..g.$.).,.H6...N
0030 - c1 e8 44 a7 49 9d d6 61-36 32 37 80 01 1a 67 38
..D.I..a627...g8
0040 - ee b7 fb 83 d8 fc 66 69-51 29 3e c4 81 38 c5 2f
..fiQ)>..8./
0050 - 62 a2 fe 65 76 20 91 b4-fb 7b e3 eb 06 fa b7 d6   b..ev
...{..
0060 - 1a 1e 2e b5 e0 ea c1 a3-d2 bf 12 bf 38 94 29 10
8.).
0070 - 79 52 de 5d ef 30 d6 a7-01 a5 74 05 69 d1 31 61
yR.].0t.i.1a
0080 - a8 05 ac 83 d1 ab 17 82-c0 cc 1d 23 96 4e d2 af
...#.N..
0090 - 74 56 aa f2 24 8c 02 f9-90 b3 e1 65 8f 81 12 a1
tV..$..e
00a0 - 79 36 72 a1 cf 0e a7 f0-fb b5 d0 42 81 5f ca 13
y6rB._..
00b0 - 24 97 a3 92 40 07 bd 5b-2c 3e 9d e8 af 3e f0 56
$...@..[,>...>.V
00c0 - 9d 00 86 b2 30 fe 4b 68-c0 2e 17 d6 aa a7 5f 5b
0.Kh.._[
00d0 - 3f 0f 30 81 a4 2b a1 fd-f6 b5 8c 3c 4e 03 cb de
?.0..+. A HelloRetryRequest will occur if the key share provided by the client
> is not acceptable to the server. By default the client will send an
> X25519 key share, so if the server does not accept that group then an
> HRR will result, e.g.
>
> $ openssl s_server -cert cert.pem -key key.pem -groups P-256
> $ openssl s_client
>
It looks option "-groups" just specifies the most preferable named groups,
but other groups still could be negotiated. Right?


Of course a HelloRetryRequest all happens at the protocol layer and is
> invisible as far as a user of the command line apps is concerned. You
> will have to look at what happens "on the wire" to actually see it in
> action - for example by using wireshark. Alternatively you can compile
> OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
> to s_server or s_client to see what protocol messages are being exchanged.
>
I found interesting things from trace logs.

BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
TLS13-AES-128-CCM-8-SHA256
TLS13-AES-128-CCM-SHA256
But with version 1.1.1-pre6, they are using the formal names,
like TLS_AES_256_GCM_SHA384.

[1] https://wiki.openssl.org/index.php/TLS1.3

Thanks!


>
> Matt
>
>
>
> >
> > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx  > >:
> >
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
> > 
> >
> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the latest beta release.
> >
> > When testing this, it's important that both sides of the
> > connection support the same TLS 1.3 draft version. OpenSSL
> > currently implements draft 26. We would like to 

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

Hi,
If just using s_server and s_client, can I test the TLS 1.3 features, likes
HelloRetryRequest and resumption?

2018-04-29 18:43 GMT+08:00 Kurt Roeckx :

> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3
>
> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the latest beta release.
>
> When testing this, it's important that both sides of the
> connection support the same TLS 1.3 draft version. OpenSSL
> currently implements draft 26. We would like to see tests
> for OpenSSL acting as client and server.
>
> https://github.com/tlswg/tls13-spec/wiki/Implementations lists
> other TLS 1.3 implementations and the draft they currently
> support. Note that the versions listed there might not be for the
> latest release. It also lists some https test servers.
>
> We would really like to see a diverse set of applictions being
> tested. Please report any results you have to us.
>
>
> Kurt
>
> --
> 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.1.1 pre release 6 published

[John Jiang]

Anyway, I can download it via
https://www.openssl.org/source/openssl-1.1.1-pre6.tar.gz

John

2018-05-02 10:48 GMT+08:00 John Jiang <john.sha.ji...@gmail.com>:

> Hi,
> I don't see the link for openssl-1.1.1-pre6.tar.gz on page
> https://www.openssl.org/source/
>
> Thanks,
> John
>
>
> 2018-05-01 21:06 GMT+08:00 OpenSSL <open...@openssl.org>:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>>OpenSSL version 1.1.1 pre release 6 (beta)
>>===
>>
>>OpenSSL - The Open Source toolkit for SSL/TLS
>>https://www.openssl.org/
>>
>>OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 6 has now
>>been made available. For details of changes and known issues see the
>>release notes at:
>>
>> https://www.openssl.org/news/openssl-1.1.1-notes.html
>>
>>Note: This OpenSSL pre-release has been provided for testing ONLY.
>>It should NOT be used for security critical purposes.
>>
>>The beta release is available for download via HTTP and FTP from the
>>following master locations (you can find the various FTP mirrors under
>>https://www.openssl.org/source/mirror.html):
>>
>>  * https://www.openssl.org/source/
>>  * ftp://ftp.openssl.org/source/
>>
>>The distribution file name is:
>>
>> o openssl-1.1.1-pre6.tar.gz
>>   Size: 8286337
>>   SHA1 checksum: d9aa6121ea9e8bfc4632566c72b376620c68ece3
>>   SHA256 checksum: 01f91c5370fe210f7172d863c5bdc5
>> dee2450c3faa98b4af2627ee6f7e128d87
>>
>>The checksums were calculated using the following commands:
>>
>> openssl sha1 openssl-1.1.1-pre6.tar.gz
>> openssl sha256 openssl-1.1.1-pre6.tar.gz
>>
>>Please download and check this beta release as soon as possible.
>>To report a bug, open an issue on GitHub:
>>
>> https://github.com/openssl/openssl/issues
>>
>>Please check the release notes and mailing lists to avoid duplicate
>>reports of known issues. (Of course, the source is also available
>>on GitHub.)
>>
>>Yours,
>>
>>The OpenSSL Project Team.
>>
>> -BEGIN PGP SIGNATURE-
>>
>> iQEcBAEBCAAGBQJa6GGbAAoJENnE0m0OYESRnqwH/jMNw6OXpGYriZphZxLNDBlR
>> YGJcNypVPcW1y5aDPlhBp9GUTAot4NPtbYpbBegPdvWaI4tA5O3+2gnCRh3xoE9e
>> k704SlJP+mmBOJSL2/9xSH1tJHNrSmXkHOpfZCr4nKJfayFDnl/H+vf6yNz3CzeB
>> Oys/VDpLPrV2ev10QNpeypu37es4shNSIRU1OEjH+iDrmTBzt9LzU6dS1rYjtuiV
>> QK/rdKV8ql0SFNIsrpLHNCT2EMfRqT/kbLcqObrczNBSunZXQF98W4XVhp7dlFBT
>> GrE8gc/KY8YGfX6kF+1Vy+9vDDKNwaLyzRKXMKUZRLnxkSBbZBREerfwaQT7m0o=
>> =O0aC
>> -END PGP SIGNATURE-
>> --
>> 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.1.1 pre release 6 published

[John Jiang]

Hi,
I don't see the link for openssl-1.1.1-pre6.tar.gz on page
https://www.openssl.org/source/

Thanks,
John

2018-05-01 21:06 GMT+08:00 OpenSSL :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>OpenSSL version 1.1.1 pre release 6 (beta)
>===
>
>OpenSSL - The Open Source toolkit for SSL/TLS
>https://www.openssl.org/
>
>OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 6 has now
>been made available. For details of changes and known issues see the
>release notes at:
>
> https://www.openssl.org/news/openssl-1.1.1-notes.html
>
>Note: This OpenSSL pre-release has been provided for testing ONLY.
>It should NOT be used for security critical purposes.
>
>The beta release is available for download via HTTP and FTP from the
>following master locations (you can find the various FTP mirrors under
>https://www.openssl.org/source/mirror.html):
>
>  * https://www.openssl.org/source/
>  * ftp://ftp.openssl.org/source/
>
>The distribution file name is:
>
> o openssl-1.1.1-pre6.tar.gz
>   Size: 8286337
>   SHA1 checksum: d9aa6121ea9e8bfc4632566c72b376620c68ece3
>   SHA256 checksum: 01f91c5370fe210f7172d863c5bdc5
> dee2450c3faa98b4af2627ee6f7e128d87
>
>The checksums were calculated using the following commands:
>
> openssl sha1 openssl-1.1.1-pre6.tar.gz
> openssl sha256 openssl-1.1.1-pre6.tar.gz
>
>Please download and check this beta release as soon as possible.
>To report a bug, open an issue on GitHub:
>
> https://github.com/openssl/openssl/issues
>
>Please check the release notes and mailing lists to avoid duplicate
>reports of known issues. (Of course, the source is also available
>on GitHub.)
>
>Yours,
>
>The OpenSSL Project Team.
>
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBCAAGBQJa6GGbAAoJENnE0m0OYESRnqwH/jMNw6OXpGYriZphZxLNDBlR
> YGJcNypVPcW1y5aDPlhBp9GUTAot4NPtbYpbBegPdvWaI4tA5O3+2gnCRh3xoE9e
> k704SlJP+mmBOJSL2/9xSH1tJHNrSmXkHOpfZCr4nKJfayFDnl/H+vf6yNz3CzeB
> Oys/VDpLPrV2ev10QNpeypu37es4shNSIRU1OEjH+iDrmTBzt9LzU6dS1rYjtuiV
> QK/rdKV8ql0SFNIsrpLHNCT2EMfRqT/kbLcqObrczNBSunZXQF98W4XVhp7dlFBT
> GrE8gc/KY8YGfX6kF+1Vy+9vDDKNwaLyzRKXMKUZRLnxkSBbZBREerfwaQT7m0o=
> =O0aC
> -END PGP SIGNATURE-
> --
> 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] How to get SNI info from s_client debug logs?

[John Jiang]

I just tried s_server, and its logs included something like "Hostname in
TLS extension".

But I still have a couple of puzzles.
1. Why does s_server need option "-servername"?
I supposed only s_client needs this option.
With my test, if only s_client specified "-servername server", the desired
certificate still was not used.
My commands like:
Server side: openssl s_server -cert cert1 -key key1 -cert2 cert2 -key2 key2
-www -accept 4433
Client side: openssl s_client -connect localhost:4433 -servername
www.server2.com < /dev/null
Here, if www.server2.com is selected, (I hoped) cert2/key2 is used. But it
didn't happen with the above case.

2. It looks options -servername and -alpn cannot work together.
Please consider the following case,
Server side: openssl s_server -cert cert1 -key key1 -cert2 cert2 -key2 key2
-servername www.server2.com -alpn h2 -www -accept 4433
Client side: openssl s_client -connect localhost:4433 -servername
www.server2.com -alpn h2 < /dev/null
With the above commands, s_client outputted "No ALPN negotiated", and cert2
was selected.
But removed "-servername www.server2.com" from server side, and re-run
client side command, it outputted "ALPN protocol: h2", but cert1 was
selected (namely, SNI didn't work).

Thanks!

2017-11-27 12:27 GMT+08:00 Kyle Hamilton <aerow...@gmail.com>:

> The -servername [host] is what causes the SNI extension to be sent.  I
> don't think its sending is put into the debug output. Do you really need it
> there?
>
> I'm pretty certain that s_server outputs it in debug output.
>
> -Kyle H
>
> On Nov 26, 2017 18:59, "John Jiang" <john.sha.ji...@gmail.com> wrote:
>
>> Hi,
>> The following is my OpenSSL version info,
>> OpenSSL 1.1.0f  25 May 2017
>>
>> I supposed the below command can give me some SNI info, but nothing was
>> found.
>> openssl s_client -debug -tlsextdebug -msg -connect 
>> -servername  < /dev/null | grep "server name"
>> But I found SNI extension with Wireshark while running the above command.
>>
>> Is it possible get SNI info with s_client?
>> Thanks!
>>
>> --
>> 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to get SNI info from s_client debug logs?

[John Jiang]

Hi,
The following is my OpenSSL version info,
OpenSSL 1.1.0f  25 May 2017

I supposed the below command can give me some SNI info, but nothing was
found.
openssl s_client -debug -tlsextdebug -msg -connect  -servername
 < /dev/null | grep "server name"
But I found SNI extension with Wireshark while running the above command.

Is it possible get SNI info with s_client?
Thanks!
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users