Re: [openssl-users] Double TLS 1.3 session ticket?

[Dennis Clarke]

On 06/20/2018 08:46 PM, Salz, Rich via openssl-users wrote:

Thanks, it does not happen with mozzilla implementation

 (tls13.crypto.mozilla.org), is this openssl specific or part of the
 specification?
   
The specification allows a server to send one or more tickets, at its discretion.




That being the case I can close this as "not a bug" :

https://bz.apache.org/bugzilla/show_bug.cgi?id=62413

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

Re: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD

[Mark Minnoch]

I'm responding to a previous post about obtaining a CD of the OpenSSL FIPS
Object Module from KeyPair Consulting rather than directly from OpenSSL.
The question is:

> Just curious, but does this satisfy Section 6.6 of the User Guide,
> since the CD does not come directly from the OpenSSL Foundation?

That's a great question. KeyPair Consulting will send a copy of the OpenSSL
FOM on CD to people that choose not to use the following options:

The best way to get the OpenSSL FIPS Object Module distribution is directly
from OpenSSL at https://www.openssl.org/source/

The second best way is to get the OpenSSL FIPS Object Module CD directly
from OpenSSL (as described in the OpenSSL FOM Security Policy and User
Guide).

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us 
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Double TLS 1.3 session ticket?

[Yann Ylavic]

On Thu, Jun 21, 2018 at 12:17 AM, Yann Ylavic  wrote:
>
> Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its
> info callback (like s_client), you'd see "SSL negotiation finished
> successfully" after each ticket, even if the server knows (or could).

Hm, actually I tried that and the real end on the server seems to be
SSL_CB_HANDSHAKE_DONE && SSL_get_state(s) == TLS_ST_OK, while
SSL_CB_HANDSHAKE_* are only transactions markers (not really limited
to tickets). Sorry for the noise.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Double TLS 1.3 session ticket?

[Yann Ylavic]

On Wed, Jun 20, 2018 at 11:49 PM, Matt Caswell  wrote:
>
> On 20/06/18 22:31, Yann Ylavic wrote:
>>
>> but I wonder if
>> announcing the start then end of the same handshake multiple times
>> could/should be avoided (i.e. handshake ends after last ticket only)?
>
> They really are individual transactions, so it makes much more sense to
> me to signal each one as a separate handshake. On the client side we
> have little choice because we don't know how many tickets the server
> will send. It seems odd to do it differently on the server.

Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its
info callback (like s_client), you'd see "SSL negotiation finished
successfully" after each ticket, even if the server knows (or could).
They are not really transactions since the client isn't supposed to
send anything in between, it's still part of the initial handshake
IMHO, and the flush seems not really needed either until the last
ticket.
Looks like it's missing some state in the machine.

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

Re: [openssl-users] Double TLS 1.3 session ticket?

[Matt Caswell]

On 20/06/18 22:31, Yann Ylavic wrote:
>>>Thanks, it does not happen with mozzilla implementation
>> (tls13.crypto.mozilla.org), is this openssl specific or part of the
>> specification?
>>
>> The specification allows a server to send one or more tickets, at its 
>> discretion.
> 
> OK thanks, I could find the relevant PR and rationale after more googling.
> 
> One caveat though, the info_callback()s can now be called multiple
> times with SSL_CB_HANDSHAKE_START/DONE (for each ticket), same
> possibly for others callbacks (if any) where the state could be
> tracked. The s_client output from the original message is misleading
> in this regard.
> 
> For instance in Apache httpd info_callback() is used to check for and
> forbid client initiated renegotiations, not a big deal since they
> shouldn't exist anymore with TLS 1.3 (so this check has been disabled
> since it's enforced by openssl in the first place), but I wonder if
> announcing the start then end of the same handshake multiple times
> could/should be avoided (i.e. handshake ends after last ticket only)?

They really are individual transactions, so it makes much more sense to
me to signal each one as a separate handshake. On the client side we
have little choice because we don't know how many tickets the server
will send. It seems odd to do it differently on the server.

Matt

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

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Jakob Bohm]

On 20/06/2018 23:07, Viktor Dukhovni wrote:



On Jun 20, 2018, at 3:44 PM, Jakob Bohm  wrote:

I believe there is a fundamental concern, impossible to handle sanely
at the CA policy level, that a CA may reasonably have certificate
hierarchies targeting people with different maximum security strength
and/or living at different times within a root certificate lifespan
(decades).

Thus it is reasonable for a particular TLS participant to dynamically
reject/ignore certificates weaker than it's own policies even if
issued by a root CA that has both strong and weak subtrees.

For that we have a coarse filter in the form of the security
level.  Thus MD5 is no longer accepted outside root CA self
signatures at the default security level 1 or higher.

One thing I forgot to mention is:


https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_callback.html

The callback interface is not yet documented, but it does allow
the application to bless or reject each algorithm for a particular
purpose:

 void SSL_CTX_set0_security_ex_data(SSL_CTX *ctx, void *ex);
 void SSL_CTX_set_security_callback(SSL_CTX *ctx,
int (*cb)(SSL *s, SSL_CTX *ctx, int op,
  int bits, int nid,
  void *other, void *ex));

When this is documented, users who really want low level
control would be able to accept or reject specific algorithms
for specific operations.

The "op" values of interest are:

SSL_SECOP_EE_KEY   /* accept/reject an EE public key */
SSL_SECOP_CA_KEY   /* accept/reject a CA public key */
SSL_SECOP_CA_MD/* accept/reject a CA hash algorithm */

If there is enough demand and contributor energy, this
interface could get documented, code examples provided, ...


What would be much more useful would be a way to put the simpler
forms in the cipher list or config options list that OpenSSL
encourages generic clients and servers to make available to end
users, thus allowing such end users (not software developers like
me) to disable broken algorithms as soon as practical to their
situation.  Also end users wanting higher security levels might
want to disable the weaker of the "currently secure" algorithms,
along with disabling the corresponding TLS ciphers suites.  So
currently, these would be approximately the users who might
manually disable 128 bit symmetric cipher suites.

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] Double TLS 1.3 session ticket?

[Yann Ylavic]

>>Thanks, it does not happen with mozzilla implementation
> (tls13.crypto.mozilla.org), is this openssl specific or part of the
> specification?
>
> The specification allows a server to send one or more tickets, at its 
> discretion.

OK thanks, I could find the relevant PR and rationale after more googling.

One caveat though, the info_callback()s can now be called multiple
times with SSL_CB_HANDSHAKE_START/DONE (for each ticket), same
possibly for others callbacks (if any) where the state could be
tracked. The s_client output from the original message is misleading
in this regard.

For instance in Apache httpd info_callback() is used to check for and
forbid client initiated renegotiations, not a big deal since they
shouldn't exist anymore with TLS 1.3 (so this check has been disabled
since it's enforced by openssl in the first place), but I wonder if
announcing the start then end of the same handshake multiple times
could/should be avoided (i.e. handshake ends after last ticket only)?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Viktor Dukhovni]

> On Jun 20, 2018, at 3:44 PM, Jakob Bohm  wrote:
> 
> I believe there is a fundamental concern, impossible to handle sanely
> at the CA policy level, that a CA may reasonably have certificate
> hierarchies targeting people with different maximum security strength
> and/or living at different times within a root certificate lifespan
> (decades).
> 
> Thus it is reasonable for a particular TLS participant to dynamically
> reject/ignore certificates weaker than it's own policies even if
> issued by a root CA that has both strong and weak subtrees.

For that we have a coarse filter in the form of the security
level.  Thus MD5 is no longer accepted outside root CA self
signatures at the default security level 1 or higher.

One thing I forgot to mention is:

   
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_callback.html

The callback interface is not yet documented, but it does allow
the application to bless or reject each algorithm for a particular
purpose:

void SSL_CTX_set0_security_ex_data(SSL_CTX *ctx, void *ex);
void SSL_CTX_set_security_callback(SSL_CTX *ctx,
   int (*cb)(SSL *s, SSL_CTX *ctx, int op,
 int bits, int nid,
 void *other, void *ex));

When this is documented, users who really want low level
control would be able to accept or reject specific algorithms
for specific operations.

The "op" values of interest are:

   SSL_SECOP_EE_KEY   /* accept/reject an EE public key */
   SSL_SECOP_CA_KEY   /* accept/reject a CA public key */
   SSL_SECOP_CA_MD/* accept/reject a CA hash algorithm */

If there is enough demand and contributor energy, this
interface could get documented, code examples provided, ...

-- 
-- 
Viktor.

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

Re: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD

[Jason Schultz]

Just curious, but does this satisfy Section 6.6 of the User Guide, since the CD 
does not come directly from the OpenSSL Foundation?


I don't have a huge need to know, just curious since as with a lot of issues 
regarding FIPS, no answer would surprise me.




From: openssl-users  on behalf of Mark 
Minnoch 
Sent: Wednesday, June 20, 2018 4:33 PM
To: openssl-users@openssl.org
Subject: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD

If you are looking for a copy of the OpenSSL FIPS Object Module (versions 2.0 
to 2.0.16) delivered to you on CD, then please send an email to 
c...@keypair.us with your shipping address.

We will send you a copy of the original OpenSSL FOM CD.

For details, see: https://keypair.us/2018/05/cd/

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile
https://KeyPair.us
https://www.linkedin.com/in/minnoch

We expertly guide technology companies in achieving their FIPS 140 goals

New blog post: You Have Your FIPS Certificate. Now 
What?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Double TLS 1.3 session ticket?

[Salz, Rich via openssl-users]

>Thanks, it does not happen with mozzilla implementation
(tls13.crypto.mozilla.org), is this openssl specific or part of the
specification?
  
The specification allows a server to send one or more tickets, at its 
discretion.

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

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Jakob Bohm]

On 20/06/2018 19:31, Viktor Dukhovni wrote:


If some root CAs, or intermediate CAs to which they delegate authority,
employ weak algorithms, your best bet is to not trust those
CAs, they should not be using weak algorithms.

TLS is not the best place to regulate (Web) PKI.

I believe there is a fundamental concern, impossible to handle sanely
at the CA policy level, that a CA may reasonably have certificate
hierarchies targeting people with different maximum security strength
and/or living at different times within a root certificate lifespan
(decades).

Thus it is reasonable for a particular TLS participant to dynamically
reject/ignore certificates weaker than it's own policies even if
issued by a root CA that has both strong and weak subtrees.

For example CA1 may, over time, have the following chains:

longtermCAroot ->
  OldIntermediary(signed-with-RSA2048-SHA1, expired or revoked) ->
    OldEECerts(all expired or revoked)

longtermCAroot ->
  crossSignedNewCAroot(signed-with-RSA2048-SHA256) ->
  NewIntermediary(signed-with-RSA4096-SHA256) ->
      CurrentEEcerts (all signed with RSA4096-SHA256)

newCAroot->
NewIntermediary(signed-with-RSA4096-SHA256) ->
    CurrentEEcerts (all signed with RSA4096-SHA256)

longtermCAroot ->
  NeverIssuedIntermediary(falsified via SHA1 weakness) ->
    FakeCert (signed with RSA4096-SHA256).

By making a TLS library able to reject certificate chains
involving RSA-MD5 (or whatever else the run time configuration
chooses to distrust), it can protect its user against trusting
the NeverIssuedIntermediary and thus the FakeCert.

CA policy and the browser forum can only choose to accept or
refuse longtermCAroot entirely.  Trusting only the self-signed
variant of crossSignedNewCAroot won't work until that has been
distributed via secure channels and all needs to trust
longtermCAroot for other uses of the unified openSSL CA directory
have disappeared.

The scenario becomes even more complicated in cases when (due to
refusals to backport algorithms to older libraries), there are
real systems that cannot accept the latest state of the art
minimum algorithms, thus in turn requiring the ongoing issuance
of certificates with old algorithm chaining to CA roots trusted
by such older systems.

The above pattern of algorithm distrust can be expected to reccur
every few decades as new attacks are found or otherwise become viable.


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] Double TLS 1.3 session ticket?

[Yann Ylavic]

On Wed, Jun 20, 2018 at 8:59 PM, Viktor Dukhovni
 wrote:
>
>
>> On Jun 20, 2018, at 2:55 PM, Yann Ylavic  wrote:
>>
>> Hi,
>>
>> connecting s_client to s_server with TLS 1.3 seems to cause two
>> successive session tickets to be sent by the server (see below).
>>
>> Is this expected?
>
> Yes.

Thanks, it does not happen with mozzilla implementation
(tls13.crypto.mozilla.org), is this openssl specific or part of the
specification?

Also, since there does not seem to be a round trip in between, any
reason to flush the BIO/socket?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Double TLS 1.3 session ticket?

[Salz, Rich via openssl-users]

>connecting s_client to s_server with TLS 1.3 seems to cause two
successive session tickets to be sent by the server (see below).

>Is this expected?
  
Yes.

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

Re: [openssl-users] Double TLS 1.3 session ticket?

[Viktor Dukhovni]

> On Jun 20, 2018, at 2:55 PM, Yann Ylavic  wrote:
> 
> Hi,
> 
> connecting s_client to s_server with TLS 1.3 seems to cause two
> successive session tickets to be sent by the server (see below).
> 
> Is this expected?

Yes.

-- 
Viktor.

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

[openssl-users] Double TLS 1.3 session ticket?

[Yann Ylavic]

Hi,

connecting s_client to s_server with TLS 1.3 seems to cause two
successive session tickets to be sent by the server (see below).

Is this expected?

$ openssl s_server -accept 127.0.0.1:4443 -cert ... -key ... -state
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
SSL_accept:SSLv3/TLS write finished
SSL_accept:TLSv1.3 early data
SSL_accept:TLSv1.3 early data
SSL_accept:SSLv3/TLS read finished
SSL_accept:SSLv3/TLS write session ticket
SSL_accept:SSLv3/TLS write session ticket
...

$ openssl s_client -connect 127.0.0.1:4443 -state
CONNECTED(0003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS read server hello
SSL_connect:TLSv1.3 read encrypted extensions
[]
SSL_connect:SSLv3/TLS read server certificate
SSL_connect:TLSv1.3 read server certificate verify
SSL_connect:SSLv3/TLS read finished
SSL_connect:SSLv3/TLS write change cipher spec
SSL_connect:SSLv3/TLS write finished
[]
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1344 bytes and written 395 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 1024 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:

PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529519509
Timeout   : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
---
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSLv3/TLS read server session ticket
read R BLOCK
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSLv3/TLS read server session ticket
read R BLOCK
...


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

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Viktor Dukhovni]

> On Jun 20, 2018, at 12:47 PM, Matt Caswell  wrote:
> 
> An OpenSSL client will enforce that the ServerKeyExchange signature is
> consistent with the sig algs that it sent. It does *not* enforce that
> the server's certificate signatures are consistent with those sig algs.
> I don't think there is any equivalent of the server's "-strict" to
> switch this checking on.
> 
> Note that in TLSv1.3 there are actually *two* sig algs extensions, i.e.
> "signature_algorithms" and "signature_algorithms_cert". The latter
> enables you to specify acceptable signature algorithms in a certificate
> chain separately from signatures algorithms in the TLSv1.3
> CertificateVerify message.

Right, certificate chain verification is the business of the X.509
code in libcrypto and lies entirely outside the SSL library.  The
SSL library sets the "security level" establishing a baseline
acceptable cryptographic strength, but otherwise, if your trusted
CAs use particular signature algorithms (per CA/B Forum practices,
...) then you'll accept the algorithms they use.

If some root CAs, or intermediate CAs to which they delegate authority,
employ weak algorithms, your best bet is to not trust those
CAs, they should not be using weak algorithms.

TLS is not the best place to regulate (Web) PKI.

At present libcrypto does not provide a fine-grained way to
restrict which signature algorithms are acceptable for a
particular invocation of X509_verify_cert(3).  The "best"
you can do is enable only the EVP algorithms you want when
when initializing the OpenSSL library.  I don't recall
whether leaving some EVP algorithms uninitialized is still
possible now that OpenSSL 1.1.x is doing automatic
self-initialization.

-- 
Viktor.

-- 
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_*

[Hubert Kario]

On Wednesday, 20 June 2018 07:51:11 CEST John Jiang wrote:
> 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.

because certificate that is usable for rsa_pss_rsae_sha256 signatures has a 
rsaEncryption Subject Public Key Info, that means it is generally usable both 
for encrypting the premaster key (TLS_RSA_* ciphers) and making signatures of 
its own (TLS_ECDHE_RSA_* ciphers), unless the KeyUsage X509v3 extension 
doesn't say otherwise...

certificate that has a rsassa-pss Subject Public Key Info key is usable *only* 
for making rsassa-pss signatures (or rsa_pss_pss_* signatures)
-- 
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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Matt Caswell]

On 20/06/18 14:51, Devang Kubavat wrote:
> Hi Matt, 
> Thanks for reply. 
> 
> I also used both functions SSL_CTX_set1_sigalgs_list() 
> SSL_CTX_set1_client_sigalgs_list() 
> but same thing happens. 
> I set client side “RSA+SHA512” using SSL_CTX_set1_sigalgs_list() but still it 
> is accepting sever certificate which has signature algorithm 
> SHA256withRSAencryption.

RFC5246 (TLSv1.2) says this about sigalgs:

   The client uses the "signature_algorithms" extension to indicate to
   the server which signature/hash algorithm pairs may be used in
   digital signatures.  The "extension_data" field of this extension
   contains a "supported_signature_algorithms" value.

There are actually 2 places in TLS where the server sends digital
signatures to the client: in the ServerKeyExchange message, and in the
server's Certificate.

An OpenSSL server will use the client's sigalgs to guide which of its
certificates are appropriate to use for the client - so if it has an
ECDSA cert but the client hasn't offered any ECDSA sig algs then it
won't use that cert.

The server will also sign the ServerKeyExchange with one of the sig algs
offered by the client.

Note though that an OpenSSL server does *not* (by default) check the
signature in its certs for compliance with the sig algs. So, for
example, if it has an ECDSA cert signed by the CA using RSA+SHA256, but
the client only offers ECDSA sig algs then it will still use that
certificate. You can configure the server to operate in "strict" mode
(e.g. using the "-strict" command line arg to s_server). In that mode it
will also check its certificate chain for compliance with the client's
sig algs.

An OpenSSL client will enforce that the ServerKeyExchange signature is
consistent with the sig algs that it sent. It does *not* enforce that
the server's certificate signatures are consistent with those sig algs.
I don't think there is any equivalent of the server's "-strict" to
switch this checking on.

Note that in TLSv1.3 there are actually *two* sig algs extensions, i.e.
"signature_algorithms" and "signature_algorithms_cert". The latter
enables you to specify acceptable signature algorithms in a certificate
chain separately from signatures algorithms in the TLSv1.3
CertificateVerify message.

Hope that helps,

Matt



> 
> Best Regards, 
> Devang
> 
> Sent from my iPhone
> 
>> On 20-Jun-2018, at 2:25 PM, Matt Caswell  wrote:
>>
>>
>>
>>> On 20/06/18 09:44, Devang Kubavat wrote:
>>> Hi all,
>>>
>>> I set the signature algorithm using in client,
>>>
>>> /* signature algorithm list */
>>>
>>> (void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);
>>>
>>>  
>>>
>>> Expected behavior: client only accepts server certificate which has
>>> signature algorithm SHA512withRSAencryption during TLS handshake.
>>>
>>>  
>>>
>>> But, here even I set “RSA+SHA512” signature algorithm, still client is
>>> accepting the server certificate which has signature algorithm
>>> SHA256withRSAencryption. Why?
>>
>> As I said in reply to your other post:
>>
>> "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting
>> signature algorithms related to *client authentication*. This is not the
>> same as the sig algs sent in the ClientHello. For that you need to use
>> SSL_CTX_set1_sigalgs_list()."
>>
>> 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] OpenSSL FIPS Object Module 2.0 on CD

[Mark Minnoch]

If you are looking for a copy of the OpenSSL FIPS Object Module (versions
2.0 to 2.0.16) delivered to you on CD, then please send an email to
c...@keypair.us with your shipping address.

We will send you a copy of the original OpenSSL FOM CD.

For details, see: https://keypair.us/2018/05/cd/

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us 
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 certification

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Oleg Paikin
> Sent: Wednesday, June 20, 2018 01:01

> We would like to add to our product OpenSSL with FIPS 140-2 module. The 
> problem is that our OS and CPUs
> are not FIPS certified. We use vxWorks 5.5.1 with 3 types of CPUs in 
> different products.

Disclaimer: I've never had to shepherd anything through the FIPS validation 
process. The following is just my understanding from reading about it.


Nothing is "FIPS certified". FIPS 140-2 does not define a "certification". 
There is FIPS validation, which if successful results in a "validation 
certificate". There's also FIPS 140 "user affirmation", which basically 
involves you saying "hey, any crypto we have is FIPS 140-2 validated in some 
other context, just not here, cross our hearts". Some customers may accept 
that, and others may not.

There's also a "FIPS Inside" claim, where you say that even if the entire 
system is not FIPS-validated, all the actual crypto is. (I'm actually not sure 
that's officially endorsed by the NIST procurement procedures doc; I've heard 
people who should know claim that it is, but I haven't looked for chapter & 
verse myself.)

Also, note that what's validated is a combination of the cryptographic 
implementation itself; cryptographic things that are done (e.g. the self-tests) 
and not done (e.g. no forbidden algorithms are used); and the runtime platform 
(the "Operational Environment"). So what you'd be getting validated is not the 
OS and CPUs themselves, but the combination of OpenSSL (and any other crypto 
software or hardware you might have), OS, and CPU. From your description, it 
sounds like you need four validations, unless your customers will accept user 
affirmation.

That's assuming your customers aren't also requesting FIPS 140-2 hardware 
tamper-resistance or some other additional assurance.

> How can we get certification for these environments? OSF answered that they 
> do not do FIPS consulting
> work anymore. Can somebody explain what is the process and cost to get such 
> certification?

The process is you find a lab that will do FIPS 104-2 validation, pay them a 
lot of money, and wait a long time (months) while they do the testing and go 
back and forth with the CMVP. History shows that the CMVP can be rather 
arbitrary. The cost is generally considerable - I think tens of thousands of 
dollars is typical.

Now, all that said, you can use OpenSSL with the FIPS container and enable FIPS 
mode without claiming you're FIPS-validated. That doesn't fulfill NIST 
procurement rules, but you may have a customer who isn't subject to those rules 
but wants to tick some "FIPS" checkbox anyway. (There's no technical advantage 
to doing so, but cryptography is an esoteric subject and sometimes people come 
up with pointless requirements.) I've known people who don't need FIPS 
validation to ask for some FIPS claim anyway, even when that claim is 
essentially meaningless. If that's the case, just make it possible for the 
customer to enable FIPS mode and let them go their merry way.

--
Michael Wojcik
Distinguished Engineer, Micro Focus
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS 140-2 certification

[Mark Minnoch]

Oleg wrote:
> We would like to add to our product OpenSSL with FIPS 140-2 module. The
problem is that our OS
> and CPUs are not FIPS certified. We use vxWorks 5.5.1 with 3 types of
CPUs in different products.
>
> How can we get certification for these environments? OSF answered that
they do not do FIPS
> consulting work anymore. Can somebody explain what is the process and
cost to get such
> certification?

My company, KeyPair Consulting, helps our Clients with FIPS 140-2 testing
for the OpenSSL FIPS Object Module. I sent Oleg a direct message with
additional details. Our service is described here:
https://keypair.us/private-labels/

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us 
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*New blog post: You Have Your FIPS Certificate. Now What?
*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL version 1.1.1 pre release 8 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.1 pre release 8 (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 8 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-pre8.tar.gz
  Size: 8334954
  SHA1 checksum: 6bca29b8b9b6cf399ad9ee585ff72c314406a757
  SHA256 checksum: 
1205cd763dd92c910cc590658a5b0774599e8587d89d6debd948f242b949321e

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1-pre8.tar.gz
openssl sha256 openssl-1.1.1-pre8.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-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsqaTYACgkQ2cTSbQ5g
RJEDPgf+MNjzRojgEzlu1IQmBthLgE2u9FL1IzTqeDGLBHolCws136AP0C8meHMi
kJUS616C5Xe8P4NYJKHQhrRoJoB8iY92aJRJTjWLEic/KWR/SmTfLLuUCQ35iArP
sT95NOhtHiYhc5iHAk0cDt42kf8ukgpLi1DcobNwzoFUma9M5y973V6fMg7OpIWu
gdSFFRjajmGJnWWmlW6+25XPBW+2otu07yRTIM+O08CEl2EcYf0TxDmncCoHS1Zu
vHt8HmRVTTzZ27hFndeD2HLeiVUe/teUfHAWe5VyqRhLcNoa20zGX2F/cvzZH8Zb
7qmwRpfVFJX0llNccuhCQVKnah1kjw==
=6mX8
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Devang Kubavat]

Hi Matt, 
Thanks for reply. 

I also used both functions SSL_CTX_set1_sigalgs_list() 
SSL_CTX_set1_client_sigalgs_list() 
but same thing happens. 
I set client side “RSA+SHA512” using SSL_CTX_set1_sigalgs_list() but still it 
is accepting sever certificate which has signature algorithm 
SHA256withRSAencryption. 

Best Regards, 
Devang

Sent from my iPhone

> On 20-Jun-2018, at 2:25 PM, Matt Caswell  wrote:
> 
> 
> 
>> On 20/06/18 09:44, Devang Kubavat wrote:
>> Hi all,
>> 
>> I set the signature algorithm using in client,
>> 
>> /* signature algorithm list */
>> 
>> (void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);
>> 
>>  
>> 
>> Expected behavior: client only accepts server certificate which has
>> signature algorithm SHA512withRSAencryption during TLS handshake.
>> 
>>  
>> 
>> But, here even I set “RSA+SHA512” signature algorithm, still client is
>> accepting the server certificate which has signature algorithm
>> SHA256withRSAencryption. Why?
> 
> As I said in reply to your other post:
> 
> "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting
> signature algorithms related to *client authentication*. This is not the
> same as the sig algs sent in the ClientHello. For that you need to use
> SSL_CTX_set1_sigalgs_list()."
> 
> 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] help : tls1.3 : tls1.2 test case failing after integration of openssl-1.1.1-pre7

[Chakrapani Reddy]

Hi Matt,

Thanks Matt for your reply. As per my understanding internal OpenSSL
header file is not included. Shall we know the way how to access SSL
object members with openssl-1.1.1-pre ?


Regards,

Chakrapani


On 19/06/18 16:18, Chakrapani Reddy wrote:
> Hello  ,
>
> Started using openssl-1.1.1-pre7 (pre-release 7) in my lab. Compiled the
> code in Linux successfully. When I run the tls1.2 test case observed
> that it's failing with openssl-1.1.1-pre7 but the same test case is
> passing with the openssl-1.1.0g.
>
> Sample code :
> SSL_CTX *ctx = SSL_CTX_new(TLSv1_2_method());
> if (ctx==0) {
> return(false);
> }
> if ((ssl_session = SSL_new(ctx))==0) {
> return(false);
> }
> if (ssl_get_new_session(ssl_session, 1)==0)  {
> return(false);
> }
> if(ssl_session->session == NULL)
> {
> printf("++ SSL_new : ssl_session->session is NULL
> +");
> }
> if(ssl_session->s3 == NULL)
> {
> printf("+ SSL_new : ssl_session->s3 is NULL +");
> }
>
> Below are the observations:
> * SSL_new() returned the valid pointer but s3 member  as NULL.
> * ssl_get_new_session() is giving the session member as NULL.

The SSL object is an opaque type, so you are not supposed to access
those members. Given that the structure definition is not in the public
header files, have you included an internal OpenSSL header file in your
project? If so, that is likely to be your problem.

Matt


On Tue, Jun 19, 2018 at 8:48 PM, Chakrapani Reddy 
wrote:

> Hello  ,
>
> Started using openssl-1.1.1-pre7 (pre-release 7) in my lab. Compiled the
> code in Linux successfully. When I run the tls1.2 test case observed that
> it's failing with openssl-1.1.1-pre7 but the same test case is passing with
> the openssl-1.1.0g.
>
> Sample code :
> SSL_CTX *ctx = SSL_CTX_new(TLSv1_2_method());
> if (ctx==0) {
> return(false);
> }
> if ((ssl_session = SSL_new(ctx))==0) {
> return(false);
> }
> if (ssl_get_new_session(ssl_session, 1)==0)  {
> return(false);
> }
> if(ssl_session->session == NULL)
> {
> printf("++ SSL_new : ssl_session->session is NULL
> +");
> }
> if(ssl_session->s3 == NULL)
> {
> printf("+ SSL_new : ssl_session->s3 is NULL +");
> }
>
> Below are the observations:
> * SSL_new() returned the valid pointer but s3 member  as NULL.
> * ssl_get_new_session() is giving the session member as NULL.
>
> Configured the below flags during the compilation process.
> ./Configure --prefix=/opt/build/openssl-1.1.1-pre7  no-tls1_3 no-shared
> enable-rc5 enable-md2 enable-ssl2 enable-weak-ssl-ciphers enable-zlib
> --with-zlib-lib=/opt/build/zlib-1.2.8/lib/ 
> --with-zlib-include=/opt/build/zlib-1.2.8/include/
> linux-x86_64
>
> Behavior is same with the configuration flag " enable-tls1_3" too.
>
> Can you please help to explain here if I am missing anything in
> integration part or known issue in openssl-1.1.1-pre7 ?
>
>
> Regards,
> Chakrapani
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Matt Caswell]

On 20/06/18 07:11, John Jiang wrote:
> 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.

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


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

Re: [openssl-users] Unexpected behaviors in TLS handshake

[Matt Caswell]

On 20/06/18 09:44, Devang Kubavat wrote:
> Hi all,
> 
> I set the signature algorithm using in client,
> 
> /* signature algorithm list */
> 
> (void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);
> 
>  
> 
> Expected behavior: client only accepts server certificate which has
> signature algorithm SHA512withRSAencryption during TLS handshake.
> 
>  
> 
> But, here even I set “RSA+SHA512” signature algorithm, still client is
> accepting the server certificate which has signature algorithm
> SHA256withRSAencryption. Why?

As I said in reply to your other post:

"The function "SSL_CTX_set1_client_sigalgs_list()" is for setting
signature algorithms related to *client authentication*. This is not the
same as the sig algs sent in the ClientHello. For that you need to use
SSL_CTX_set1_sigalgs_list()."

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

[openssl-users] Unexpected behaviors in TLS handshake

[Devang Kubavat]

Hi all,

I set the signature algorithm using in client,
/* signature algorithm list */
(void)SSL_CTX_set1_client_sigalgs_list(ctx, "RSA+SHA512");

Expected behavior: client only accepts server certificate which has signature 
algorithm SHA512withRSAencryption during TLS handshake.

But, here even I set "RSA+SHA512" signature algorithm, still client is 
accepting the server certificate which has signature algorithm 
SHA256withRSAencryption. Why?

Best Regards,
Devang

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

[openssl-users] FIPS 140-2 certification

[Oleg Paikin]

Hi

We would like to add to our product OpenSSL with FIPS 140-2 module. The problem 
is that our OS and CPUs are not FIPS certified. We use vxWorks 5.5.1 with 3 
types of CPUs in different products.

How can we get certification for these environments? OSF answered that they do 
not do FIPS consulting work anymore. Can somebody explain what is the process 
and cost to get such certification?

Regards,
 Oleg


-- 
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