Re: openssl 1.0.2 with TLS 1.2

[Salz, Rich via openssl-users]

  *   I can’t find documentation on how to tell TLS where to look.

Not sure about 1.0.2, but “openssl version -a” should show you the CERT 
directory.

BTW, that’s an old release, you should upgrade if possible.

openssl 1.0.2 with TLS 1.2

[Anne M. Hammond]

I built openssl 1.0.2 from the tar.gz file.

I am trying to verify a connection, but TLS does not find the ca-bundle.crt 
unless it is on the command line:

/usr/local/openssl/bin/openssl s_client -showcerts  -connect mta3.edu:25 
-starttls smtp

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 653E180E0E46DB0E2B268F2FB7AB583B66F31269AD7F073FF23531C14A7DAE66
Session-ID-ctx: 
Master-Key: 
7D54E27BFBAC1422F3C23055359E222DE1865A71F8DD7CF0B9FAAE2CEBA8D3EE17AA27A183206B814EDA0016EA699020
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1571773604
Timeout   : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)


/usr/local/openssl/bin/openssl s_client -showcerts -CAfile 
/usr/local/openssl/ssl/certs/ca-bundle.crt -connect mta3.edu:25 -starttls smtp

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 68EB6663064D12857FFFB061F29BF4DFB081A8322A30AF292E8CC88CEE5F7B47
Session-ID-ctx: 
Master-Key: 
5FF67384CB91433D39ACA430E4AD447A3C854B865A8E71FB46AAD79C5CCFB56B2FB57AFED08FA73227BCFBFDE0633C85
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1571773646
Timeout   : 300 (sec)
Verify return code: 0 (ok)


“Why does  faile with a certificate verify error?” faq says:
this typically means that the CA certificate must be placed in a directory or 
file and the relevant program configured to read it.

I can’t find documentation on how to tell TLS where to look.

I’ve tried placing ca-bundle.crt in
/usr/local/openssl/ssl/certs/
/etc/pki/tls/certs

Any pointers appreciated.

Anne

Re: Should SSL_get_servername() depend on SNI callback (no-)ACK?

[Stephen Farrell]

Hiya,

On 22/10/2019 17:09, Yann Ylavic wrote:
> Sorry for the shortcut, by "tlsext_hostname" I meant the name of the
> field in SSL_SESSION_ASN1.
> My observation is that when browsers resume a session, s->hit is set
> but s->session->ext.hostname is NULL, which I interpret as no SNI
> found in the SSL_SESSION (and thus no SNI encoded in the session
> ticket, presumably).
> On the other hand, the SNI is always in ClientHello (though there is
> no way to match it against the session's).

FWIW, I also had to play about a bit with that to get ESNI
working with tickets. I can chase down the bits of code for
that in my fork [1] if it's useful.

Cheers,
S.

[1] https://github.com/sftcd/openssl/


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Should SSL_get_servername() depend on SNI callback (no-)ACK?

[Yann Ylavic]

On Tue, Oct 22, 2019 at 5:09 PM Benjamin Kaduk  wrote:
>
> There's some (additional?) discussion on this topic in
> https://github.com/openssl/openssl/pull/10018 .  A couple comments inline, 
> though...

Thanks, will look at it.  More comment below too...

> On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote:
> >
> > And it _seems_ that browsers (or Chrome only?) don't set a
> > tlsext_hostname in their session (ASN1) on resumption, so
>
> I don't understand what you mean by "set a tlsext_hostname in their session 
> (ASN1)
> on resumption".  Are you saying that browsers do not send the 
> server_name_indication
> extension in the ClientHello for resumption handshakes?

Sorry for the shortcut, by "tlsext_hostname" I meant the name of the
field in SSL_SESSION_ASN1.
My observation is that when browsers resume a session, s->hit is set
but s->session->ext.hostname is NULL, which I interpret as no SNI
found in the SSL_SESSION (and thus no SNI encoded in the session
ticket, presumably).
On the other hand, the SNI is always in ClientHello (though there is
no way to match it against the session's).

>
>   Note that the documentation for SSL_get_servername() is in
> the page for SSL_CTX_set_tlsext_servername_callback() and claims to
> return the value from the Client Hello (if present).  Yet, historically,
> prior to TLS 1.3 on resumption we did not even look at the ClientHello
> to see whether the extension was present; we just resumed and thus the
> "Client Hello" in the above would be the *initial* ClientHello.

This requires that the initial SNI be encoded in the session (ticket),
does this changed with TLS 1.3 somehow?

>  This
> was perhaps tolerable if the servername callback was never called, if
> you assume that the API would only be called from that callback, but
> that assumption is no longer anywhere close to true.

Yes, I found this "issue" by trying to modify Apache httpd, which was
previously using the SNI callback to select the right TLS
configuration (per virtual host), to now do that in the new
ClientHello callback (which allows for setting the configured TLS
protocol version too, whereas the SNI callback is too late for that).
When doing this, I naively first removed the SNI callback completely,
and discovered that further call to SSL_get_hostname() was returning
NULL, for some cases (resumption)...


Regards,
Yann.

RE: openssl and external card reader support in TLS

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> tobias.w...@t-systems.com
> Sent: Tuesday, October 22, 2019 07:03

> I need to implement support for the external authentication of a card reader 
> within a
> TLS handshake. We did this already with PKCS11 using the C_Sign function and 
> it is
> working fine.

> Now I need to implement the same functionality in another use case with 
> openssl for
> TLS handshake.

> My Question is there a callback I can use or do I need to implement my own 
> ENGINE?

OpenSSL includes a PKCS#11 engine. I've used it in the past to interact with 
some HSMs for cryptographic operations such as code signing. While some 
research and additional software may be required to get all the PKCS#11 ducks 
in a row, it sounds like you've already successfully used PKCS#11 with your 
device, so I'd expect using it with OpenSSL will be fairly straightforward.

You can find examples of using the openssl command-line utility with the 
PKCS#11 engine online. That's a good way to get started; it will let you 
confirm what settings and commands you need.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: Should SSL_get_servername() depend on SNI callback (no-)ACK?

[Benjamin Kaduk via openssl-users]

There's some (additional?) discussion on this topic in
https://github.com/openssl/openssl/pull/10018 .  A couple comments inline, 
though...

On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote:
> Hi,
> 
> in master (and 1.1.1), SSL_get_servername() returns either
> s->session->ext.hostname (when s->hit == 1), or s->ext.hostname
> (otherwise).
> 
> It seems, according to final_server_name(), that
> s->session->ext.hostname is set only:
> if (sent && ret == SSL_TLSEXT_ERR_OK && (!s->hit || SSL_IS_TLS13(s))) 
> {
> ...
> s->session->ext.hostname = OPENSSL_strdup(s->ext.hostname);
> ...
> }
> that is if a SNI callback exists and returns OK (no callback
> defaulting to NOACK).
> 
> And it _seems_ that browsers (or Chrome only?) don't set a
> tlsext_hostname in their session (ASN1) on resumption, so

I don't understand what you mean by "set a tlsext_hostname in their session 
(ASN1)
on resumption".  Are you saying that browsers do not send the 
server_name_indication
extension in the ClientHello for resumption handshakes?

> s->session->ext.hostname isn't set by that either. Note that this
> leaves s->servername_done = 0 in the below code from
> tls_parse_ctos_server_name():
> if (s->hit) {
> /*
>  * TODO(openssl-team): if the SNI doesn't match, we MUST
>  * fall back to a full handshake.
>  */
> s->servername_done = (s->session->ext.hostname != NULL)
> && PACKET_equal(, s->session->ext.hostname,
> strlen(s->session->ext.hostname));
> 
> if (!s->servername_done && s->session->ext.hostname != NULL)
> s->ext.early_data_ok = 0;
> }
> 
> So it's possible that, on session resumption (s->hit == 1),
> SSL_get_servername() returns NULL (unset s->session->ext.hostname)
> even though an SNI is provided by ClientHello. Shouldn't it return the
> ClientHello's SNI regardless of the presence/return of the callback?
> Something like the below (where s->servername_done is also tested)?

There's something of a philosophical debate; some additional (heated)
discussion can be found in https://github.com/openssl/openssl/pull/7115
but I think the real cause of problems in this space is that
the SSL_get_servername() API contract has been underspecified from the
start.  Note that the documentation for SSL_get_servername() is in
the page for SSL_CTX_set_tlsext_servername_callback() and claims to
return the value from the Client Hello (if present).  Yet, historically,
prior to TLS 1.3 on resumption we did not even look at the ClientHello
to see whether the extension was present; we just resumed and thus the
"Client Hello" in the above would be the *initial* ClientHello.  This
was perhaps tolerable if the servername callback was never called, if
you assume that the API would only be called from that callback, but
that assumption is no longer anywhere close to true.

-Ben

> const char *SSL_get_servername(const SSL *s, const int type)
> {
> if (type != TLSEXT_NAMETYPE_host_name)
> return NULL;
> 
> /*
>  * SNI is not negotiated in pre-TLS-1.3 resumption flows, so fake up an
>  * SNI value to return if we are resuming/resumed.  N.B. that we still
>  * call the relevant callbacks for such resumption flows, and callbacks
>  * might error out if there is not a SNI value available.
>  */
> if (s->hit && s->servername_done)
> return s->session->ext.hostname;
> return s->ext.hostname;
> }
> 
> 
> Regards,
> Yann.

Re: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module

[Dr Paul Dale]

The FIPS module source code can’t be changed without losing validation.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 22 Oct 2019, at 11:46 pm, Salman Baset  wrote:
> 
> Thank you very much. This is helpful. Will the support also include any 
> updates to the FIPS compatible part, or is that out of scope because any 
> update essentially invalidates existing FIPS cert for potential use?
> 
> 
> On Mon, Oct 21, 2019 at 11:56 AM Dr Paul Dale  > wrote:
> The EOL date for OpenSSL 1.0.2 will not be extended.
> 
> It is possible to purchase premium level support which will provide 1.0.2 
> updates beyond its normal end of life.  See: 
> https://www.openssl.org/support/contracts.html#premium 
> 
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 21 Oct 2019, at 9:11 pm, Salman Baset > > wrote:
>> 
>> Hello everyone,
>> 
>> I was wondering if there is any update on getting a new FIPS-validated 
>> module for OpenSSL by the end of this year (before EOL of 1.0.2), as was 
>> mentioned in this blog post:
>> https://www.openssl.org/blog/blog/2018/09/25/fips/ 
>> 
>> 
>> According to this email, the new FIPS module is dependent on OpenSSL 3.0, 
>> whose release timing is not certain yet.
>> https://mta.openssl.org/pipermail/openssl-users/2019-February/009836.html 
>> 
>> 
>> I will appreciate if someone can provide an update on the new FIPS timeline 
>> as that will help folks who are looking to depend on OpenSSL's 
>> FIPS-validated modules in the next 6-9 months or so.
>> 
>> Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 till 
>> the new FIPS module/OpenSSL 3.0 becomes available?
>> 
>> Thanks
>> Salman
> 

Re: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module

[Salman Baset]

Thank you very much. This is helpful. Will the support also include any
updates to the FIPS compatible part, or is that out of scope because any
update essentially invalidates existing FIPS cert for potential use?


On Mon, Oct 21, 2019 at 11:56 AM Dr Paul Dale  wrote:

> The EOL date for OpenSSL 1.0.2 will not be extended.
>
> It is possible to purchase premium level support which will provide 1.0.2
> updates beyond its normal end of life.  See:
> https://www.openssl.org/support/contracts.html#premium
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 21 Oct 2019, at 9:11 pm, Salman Baset  wrote:
>
> Hello everyone,
>
> I was wondering if there is any update on getting a new FIPS-validated
> module for OpenSSL by the end of this year (before EOL of 1.0.2), as was
> mentioned in this blog post:
> https://www.openssl.org/blog/blog/2018/09/25/fips/
>
> According to this email, the new FIPS module is dependent on OpenSSL 3.0,
> whose release timing is not certain yet.
> https://mta.openssl.org/pipermail/openssl-users/2019-February/009836.html
>
> I will appreciate if someone can provide an update on the new FIPS
> timeline as that will help folks who are looking to depend on OpenSSL's
> FIPS-validated modules in the next 6-9 months or so.
>
> Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2
> till the new FIPS module/OpenSSL 3.0 becomes available?
>
> Thanks
> Salman
>
>
>

openssl and external card reader support in TLS

[Tobias.Wolf]

I need to implement support for the external authentication of a card reader 
within a TLS handshake. We did this already with PKCS11 using the C_Sign 
function and it is working fine.
Now I need to implement the same functionality in another use case with openssl 
for TLS handshake.
My Question is there a callback I can use or do I need to implement my own 
ENGINE? I want to avoid implementing the ENGINE interface, because that is a 
lot of work and maybe over engineered for this scenario, right?

Should SSL_get_servername() depend on SNI callback (no-)ACK?

[Yann Ylavic]

Hi,

in master (and 1.1.1), SSL_get_servername() returns either
s->session->ext.hostname (when s->hit == 1), or s->ext.hostname
(otherwise).

It seems, according to final_server_name(), that
s->session->ext.hostname is set only:
if (sent && ret == SSL_TLSEXT_ERR_OK && (!s->hit || SSL_IS_TLS13(s))) {
...
s->session->ext.hostname = OPENSSL_strdup(s->ext.hostname);
...
}
that is if a SNI callback exists and returns OK (no callback
defaulting to NOACK).

And it _seems_ that browsers (or Chrome only?) don't set a
tlsext_hostname in their session (ASN1) on resumption, so
s->session->ext.hostname isn't set by that either. Note that this
leaves s->servername_done = 0 in the below code from
tls_parse_ctos_server_name():
if (s->hit) {
/*
 * TODO(openssl-team): if the SNI doesn't match, we MUST
 * fall back to a full handshake.
 */
s->servername_done = (s->session->ext.hostname != NULL)
&& PACKET_equal(, s->session->ext.hostname,
strlen(s->session->ext.hostname));

if (!s->servername_done && s->session->ext.hostname != NULL)
s->ext.early_data_ok = 0;
}

So it's possible that, on session resumption (s->hit == 1),
SSL_get_servername() returns NULL (unset s->session->ext.hostname)
even though an SNI is provided by ClientHello. Shouldn't it return the
ClientHello's SNI regardless of the presence/return of the callback?
Something like the below (where s->servername_done is also tested)?

const char *SSL_get_servername(const SSL *s, const int type)
{
if (type != TLSEXT_NAMETYPE_host_name)
return NULL;

/*
 * SNI is not negotiated in pre-TLS-1.3 resumption flows, so fake up an
 * SNI value to return if we are resuming/resumed.  N.B. that we still
 * call the relevant callbacks for such resumption flows, and callbacks
 * might error out if there is not a SNI value available.
 */
if (s->hit && s->servername_done)
return s->session->ext.hostname;
return s->ext.hostname;
}


Regards,
Yann.

RE: OpenSSL compilation errors in Windows

[Nagalakshmi V J]

Hi Matt,

Could you please help to get any clue on the ACCESSOR APIs of the following.

I tried searching APIs. Not getting exact matches. Referred the below links.

https://www.openssl.org/docs/man1.1.1/man3/SSL_set_info_callback.html
https://www.openssl.org/docs/man1.1.1/man3/EVP_md5.html

Getting similar error for the below code.

tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf),
 pGenerator->master_secret,sizeof(pGenerator->master_secret),
 km,tmp,num);

Struct ssl_ctx_st {
...
const EVP_MD *md5;  /* For SSLv3/TLSv1 'ssl3-md5' */
const EVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */
...
}

struct evp_md_st {
int type;
int pkey_type;
int md_size;
unsigned long flags;
int (*init) (EVP_MD_CTX *ctx);
int (*update) (EVP_MD_CTX *ctx, const void *data, size_t count);
int (*final) (EVP_MD_CTX *ctx, unsigned char *md);
int (*copy) (EVP_MD_CTX *to, const EVP_MD_CTX *from);
int (*cleanup) (EVP_MD_CTX *ctx);
int block_size;
int ctx_size;   /* how big does the ctx->md_data need to be */
/* control function */
int (*md_ctrl) (EVP_MD_CTX *ctx, int cmd, int p1, void *p2);
} /* EVP_MD */ ;


Thanks and regards,
Nagalakshmi

From: Nagalakshmi V J 
Sent: Tuesday, October 22, 2019 9:39 AM
To: Matt Caswell ; Nagalakshmi V J 
; openssl-users@openssl.org
Subject: Re: OpenSSL compilation errors in Windows

Hi Matt,

Yes. Exactly we followed the same and able to resolve errors. Thank you so much 
for the support and guidance. I'll get back if any further errors.

Thanks & Regards,
Nagalakshmi V J

From: Matt Caswell mailto:m...@openssl.org>>
Sent: 21 October 2019 21:26:32
To: Nagalakshmi V J 
mailto:nagalakshm...@altran.com>>; 
openssl-users@openssl.org 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL compilation errors in Windows

** This mail has been sent from an external source **


On 20/10/2019 08:43, Nagalakshmi V J wrote:
> Hi Matt,
>
> This link is having few APIS. But for getting master_key_length, I don't
> find any API. Not sure if we need to use getMasterKey API for that.

You can use SSL_SESSION_get_master_key() for this.

Note this comment in the RETURN VALUES section:

"For the other functions, if outlen is greater than 0 then these
functions return the number of bytes actually copied, which will be less
than or equal to outlen. If outlen is 0 then these functions return the
maximum number of bytes they would copy -- that is, the length of the
underlying field."

So to discover the master_key_length call the function with outlen to
zero. You can then allocate an appropriate sized buffer and call the
function again in order to get the actual master key.

Matt


>
> I will try to use these APIs and get back.
>
> Thanks & Regards,
> Nagalakshmi V J
> 
> *From:* Matt Caswell mailto:m...@openssl.org>>
> *Sent:* 18 October 2019 14:48:33
> *To:* Nagalakshmi V J 
> mailto:nagalakshm...@altran.com>>;
> openssl-users@openssl.org 
> mailto:openssl-users@openssl.org>>
> *Subject:* Re: OpenSSL compilation errors in Windows
>
> ** This mail has been sent from an external source **
>
>
> On 18/10/2019 11:49, Nagalakshmi V J wrote:
>> Now the issue is SSL_session structure is also having accessor APIs
>> which I am not aware of. So I need to get the APIs for accessing the
>> master_key_length,etc.. given in the above code. Those are not listed
>> in the openssl link referred.
>
> On this page look a the various functions beginning with "SSL_SESSION_"
> in the name:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_=DwICaQ=cxWN2QSDopt5SklNfbjIjg=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4=
>
> From the code sample you gave you are probably mostly interested in the
> functions on this page:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html=DwICaQ=cxWN2QSDopt5SklNfbjIjg=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI=
>
> Matt
>
> =
> Please refer to https://northamerica.altran.com/email-disclaimer
> for important disclosures regarding this electronic communication.
> =
=
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=
=
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this 

OpenSSL blog post by APNIC

[Dr Paul Dale]

An APNIC article loosely based on the OpenSSL presentation at AusCERT earlier 
this year:

https://blog.apnic.net/2019/10/21/openssl-3-0-accelerating-forwards/ 



Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia