Re: [openssl-users] Intermediate certificates

[Dave Thompson]

> From: openssl-users On Behalf Of Kurt Roeckx
> Sent: Tuesday, January 27, 2015 17:14

> On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote:

> What browsers do is cache the intermediate certificates.  

That's one possibility. Another is that it uses AuthorityInfoAccess 
to fetch the cert automatically, which OpenSSL currently does not
(unless you figure out a custom X509_LOOKUP to do so).


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

Re: [openssl-users] Intermediate certificates

[Salz, Rich]

> Browsers have too many work arounds for broken sites which results in
> those sites not actually getting fixed.

Because if the site doesn't work, the user will blame the browser and switch. :(
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Intermediate certificates

[Kurt Roeckx]

On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote:
> 
> > It is unfortunate that browsers "lend a helping hand" to such sites.
> So, you want to say that browsers trust connections that don't provide 
> intermediate certs during SSL handhake?
> As I know most browsers have also intermediate certs in their stores as 
> builtin objects and also as received during handshakes.
> That's why any documentation how to set intermediate certificates for my SSL 
> connections will be very needed.

What browsers do is cache the intermediate certificates.  If a
sites fails to send them, the browser can still find it in it's
cache and use those cached intermediate certificates to do the
validation.

If the missing intermediate certificate is not cached the site
will not work in the browser.  But if you then visit a site that
has the same intermediate certificate that does send it, and then
go back to the broken site it will suddenly work.

Browsers have too many work arounds for broken sites which results
in those sites not actually getting fixed.


Kurt

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

Re: [openssl-users] Hostname validation

[Serj]

28.01.2015, 00:04, "Dr. Stephen Henson" :
> It's this:
>
>    param = SSL_get0_param(ssl);
>
> Because SSL_get0_param retrieves the internal pointer to parameters used by
> ssl: so if you modify those parameters the modified versions will be used by
> ssl.

Thanks, Stephen. Now it's clear.

--
Best Regards,

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

Re: [openssl-users] Intermediate certificates

[Serj]

27.01.2015, 23:15, "Viktor Dukhovni" :
> Indeed some websites are misconfigured.
> But www.verisign.com is not among them:
> This is not needed for properly configured servers, such as
> www.verisign.com.
Ok. Seems to be I don't set the last root for www.verisign.com in my trusted 
root certs and only that's why I got a error:
Verify return code: 20 (unable to get local issuer certificate)


> While providing additional "untrusted" (intermediate) certificates
> is possible, it is complex and the right solution is for the broken
> sites to fix their certificate chain configuration.

Ok. But is there any documentation how to set intermediate certificates for my 
SSL connections? Maybe I want to support these broken sites... 


> It is unfortunate that browsers "lend a helping hand" to such sites.
So, you want to say that browsers trust connections that don't provide 
intermediate certs during SSL handhake?
As I know most browsers have also intermediate certs in their stores as builtin 
objects and also as received during handshakes.
That's why any documentation how to set intermediate certificates for my SSL 
connections will be very needed.



Thank you for answers, Viktor, once again.
And I looking forward to your reply...

--
Best Regards,

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

Re: [openssl-users] Hostname validation

[Serj]

Hi, Viktor.

27.01.2015, 23:07, "Viktor Dukhovni" :
> It is complete enough.  The word "mumble" is not meant to be taken

You full code from wiki is:

const char *servername;
SSL *ssl;
X509_VERIFY_PARAM *param;

servername = "www.example.com";
ssl = SSL_new(...);
param = SSL_get0_param(ssl);

/* Enable automatic hostname checks */
X509_VERIFY_PARAM_set_hostflags(param, 
X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
X509_VERIFY_PARAM_set1_host(param, servername, 0);

/* Configure a non-zero callback if desired */
SSL_set_verify(ssl, SSL_VERIFY_PEER, 0);

/*
 * Establish SSL connection, hostname should be checked
 * automatically test with a hostname that should not match,
 * the connection will fail (unless you specify a callback
 * that returns despite the verification failure.  In that
 * case SSL_get_verify_status() can expose the problem after
 * connection completion.
 */
 ...

You set here only "param":
X509_VERIFY_PARAM_set_hostflags(param, 
X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
X509_VERIFY_PARAM_set1_host(param, servername, 0);

But how this variable is associated with "ssl" object or "ctx" object?
I don't understand really! Please explain more in detail.

I know this function only SSL_CTX_set1_param() that associates "param"  with 
context "ctx".


--
Best Regards,

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

Re: [openssl-users] Hostname validation

[Dr. Stephen Henson]

On Tue, Jan 27, 2015, Serj wrote:

> Hi, Viktor.
> 
> 27.01.2015, 23:07, "Viktor Dukhovni" :
> > It is complete enough.  The word "mumble" is not meant to be taken
> 
> You full code from wiki is:
> 
> const char *servername;
>   SSL *ssl;
>   X509_VERIFY_PARAM *param;
> 
>   servername = "www.example.com";
>   ssl = SSL_new(...);
>   param = SSL_get0_param(ssl);
> 
>   /* Enable automatic hostname checks */
>   X509_VERIFY_PARAM_set_hostflags(param, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
>   X509_VERIFY_PARAM_set1_host(param, servername, 0);
> 
>   /* Configure a non-zero callback if desired */
>   SSL_set_verify(ssl, SSL_VERIFY_PEER, 0);
> 
>   /*
>* Establish SSL connection, hostname should be checked
>* automatically test with a hostname that should not match,
>* the connection will fail (unless you specify a callback
>* that returns despite the verification failure.  In that
>* case SSL_get_verify_status() can expose the problem after
>* connection completion.
>*/
>...
> 
> You set here only "param":
>   X509_VERIFY_PARAM_set_hostflags(param, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
>   X509_VERIFY_PARAM_set1_host(param, servername, 0);
> 
> But how this variable is associated with "ssl" object or "ctx" object?
> I don't understand really! Please explain more in detail.
> 

It's this:

   param = SSL_get0_param(ssl);

Because SSL_get0_param retrieves the internal pointer to parameters used by 
ssl: so if you modify those parameters the modified versions will be used by
ssl.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Intermediate certificates

[Serj]

Hello.

Some web-sites don't send all intermediate certs during "SSL Handshake". For 
example, www.verisign.com sends only server's cert but doesn't send next 
intermediate cert:

s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL 
SGC CA 
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - 
For authorized use only/CN=VeriSign Class 3 Public Primary Certification 
Authority - G5

So, I need to set a list of intermediate certs for my SSL connections. How to 
do this?

With SSL_CTX_load_verify_locations() I can set only trusted root certs, but not 
intermediate certs.


--
Best Regards,

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

Re: [openssl-users] Hostname validation

[Serj]

Hi, Viktor.

27.01.2015, 20:23, "Viktor Dukhovni" :
> I would set SSL verification parameters is to obtain the parameter
> handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(),
> and use the various X509_VERIFY_PARAM_mumble() functions to tweak
> the parameter object in place.

Why are not there any X509_VERIFY_PARAM_mumble() functions in your code?
So your code is not complete?
And if so why it was already added to wiki here: 
http://wiki.openssl.org/index.php/Hostname_validation


> As I mentioned, this function should be documented, but is not yet.
> The documentation for these functions is not yet written.  The way
> Yes, these need (more) documentation.

That's why maybe it is better to use X509_check_host() in "post conection 
checks" now?

It's strangely, why I read in documentaion:
--
Applications are strongly advised to use this interface in preference to 
explicitly calling X509_check_host(3), hostname checks are out of scope with 
the DANE-EE(3) certificate usage, and the internal check will be suppressed as 
appropriate when DANE support is added to OpenSSL.
and no any documentation on how to set properly params for SSL or CTX!

NOTES
Applications are encouraged to use X509_VERIFY_PARAM_set1_host() rather than 
explicitly calling X509_check_host(3). Host name checks are out of scope with 
the DANE-EE(3) certificate usage, and the internal checks will be suppressed as 
appropriate when DANE support is added to OpenSSL.
--
and no any documentation on how to set properly params for SSL or CTX!


Maybe this code is right, while there is no full documentation yet:

  char servername[]="www.openssl.org\x0";
  X509_VERIFY_PARAM *param;
  param = X509_VERIFY_PARAM_new();

  //enable automatic hostname checks 
  X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
  X509_VERIFY_PARAM_set1_host(param, servername,0);
  SSL_CTX_set1_param(ctx, param); //is right if combined by a bitwise 'OR' 
operation
  
  //free param
  X509_VERIFY_PARAM_free(param);


--
Best Regards,

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

Re: [openssl-users] Intermediate certificates

[Viktor Dukhovni]

On Tue, Jan 27, 2015 at 10:21:01PM +0300, Serj wrote:

> Some web-sites don't send all intermediate certs during "SSL Handshake".

Indeed some websites are misconfigured.

> For example, www.verisign.com sends only server's cert but doesn't send next 
> intermediate cert:

But www.verisign.com is not among them:

$ sleep 2 |
openssl s_client -showcerts -connect www.verisign.com:443 2>&1 |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs -noout

subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private
 
Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain
 View/street=350 Ellis Street/O=Symantec Corporation/OU=Infrastructure 
Operations  /CN=www.verisign.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL 
SGC CA

subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL 
SGC CA
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary 
Certification Authority - G5

subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary 
Certification Authority - G5
issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification 
Authority


> So, I need to set a list of intermediate certs for my SSL connections. How to 
> do this?
> 
> With SSL_CTX_load_verify_locations() I can set only trusted root certs, but 
> not intermediate certs.

This is not needed for properly configured servers, such as
www.verisign.com.

While providing additional "untrusted" (intermediate) certificates
is possible, it is complex and the right solution is for the broken
sites to fix their certificate chain configuration.

It is unfortunate that browsers "lend a helping hand" to such sites.

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

Re: [openssl-users] Hostname validation

[Viktor Dukhovni]

On Tue, Jan 27, 2015 at 10:09:38PM +0300, Serj wrote:

> 27.01.2015, 20:23, "Viktor Dukhovni" :
> > I would set SSL verification parameters is to obtain the parameter
> > handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(),
> > and use the various X509_VERIFY_PARAM_mumble() functions to tweak
> > the parameter object in place.
> 
> Why are not there any X509_VERIFY_PARAM_mumble() functions in your code?
> So your code is not complete?

It is complete enough.  The word "mumble" is not meant to be taken
literally.  The phrase:

"various X509_VERIFY_PARAM_mumble() functions"

means any of:

X509_VERIFY_PARAM_set_hostflags()
X509_VERIFY_PARAM_set1_host()
...


> > As I mentioned, this function should be documented, but is not yet.
> > The documentation for these functions is not yet written. ?The way
> > Yes, these need (more) documentation.
> 
> That's why maybe it is better to use X509_check_host() in "post conection 
> checks" now?

No, it is better to use the parameter functions, and also to document
the missing SSL_get0_param().

> NOTES
> Applications are encouraged to use X509_VERIFY_PARAM_set1_host()
> rather than explicitly calling X509_check_host(3). Host name checks
> are out of scope with the DANE-EE(3) certificate usage, and the
> internal checks will be suppressed as appropriate when DANE support
> is added to OpenSSL.
> --
> and no any documentation on how to set properly params for SSL or CTX!

Example code should likely be added to that document.

> Maybe this code is right, while there is no full documentation yet:
> 
>   char servername[]="www.openssl.org\x0";
>   X509_VERIFY_PARAM *param;
>   param = X509_VERIFY_PARAM_new();
> 
>   //enable automatic hostname checks 
>   X509_VERIFY_PARAM_set_hostflags(param, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
>   X509_VERIFY_PARAM_set1_host(param, servername,0);
>   SSL_CTX_set1_param(ctx, param); //is right if combined by a bitwise 'OR' 
> operation
>   
>   //free param
>   X509_VERIFY_PARAM_free(param);

No, use the code example I provided.  The above sets the hostname
in the global context, where it does not belong.  My original
message is below:

On Sun, Jan 25, 2015 at 05:57:06PM +, Viktor Dukhovni wrote:

> On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote:
> 
> > What is the best way to make hostname validation?
> > 
> > 1. http://wiki.openssl.org/index.php/Hostname_validation
> > 2. X509_check_host that was added in OpenSSL 1.1.0.
> 
> The X509_check_host() interface is also available in OpenSSL 1.0.2
> released a few days ago
> 
> https://www.openssl.org/docs/crypto/X509_check_host.html
> 
> (the documentation should be updated to note the earlier availability).
> 
> Starting with 1.0.2, you can also ask OpenSSL to automatically
> perform hostname checks during the SSL handshake on the application's
> behalf:
> 
> https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html
> https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html
> https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html
> https://www.openssl.org/docs/ssl/SSL_set_verify.html
> 
> Sadly, we're still lacking documentation of SSL_get0_param() which
> is needed for a complete SSL hostname check recipe:
> 
>   const char *servername;
>   SSL *ssl;
>   X509_VERIFY_PARAM *param;
> 
>   servername = "www.example.com";
>   ssl = SSL_new(...);
>   param = SSL_get0_param(ssl);
> 
>   /* Enable automatic hostname checks */
>   X509_VERIFY_PARAM_set_hostflags(param, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
>   X509_VERIFY_PARAM_set1_host(param, servername, 0);
> 
>   /* Configure a non-zero callback if desired */
>   SSL_set_verify(ssl, SSL_VERIFY_PEER, 0);
> 
>   /*
>* Establish SSL connection, hostname should be checked
>* automatically test with a hostname that should not match,
>* the connection will fail (unless you specify a callback
>* that returns despite the verification failure.  In that
>* case SSL_get_verify_status() can expose the problem after
>* connection completion.
>*/
>...
> 
> > I don't know does the first one support wildcards or no! Seems
> > to be: how does Curl_cert_hostcheck work - is the answer, but I
> > don't know how it works.
> 
> Wildcard support is configured via the flags documented for X509_check_host(),
> the two most frequently useful are:
> 
>   X509_CHECK_FLAG_NO_WILDCARDS
>   X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS

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

[openssl-users] TSLEXT_TYPE_opaque_prf_input

[Salz, Rich]

This is an implementation of an IETF draft that expired seven years ago.  Is 
anyone using it?

--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

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

Re: [openssl-users] Using FIPS mode and modifying apps

[Steve Marquess]

On 01/27/2015 11:09 AM, jonetsu wrote:
> "Steve Marquess" wrote on 01/27/15 09:18: Thank
> you (and Tom) for your comments - much appreciated.
> 
>> Tom Francis nailed the answer to this one. We did design the FIPS
>> module + "FIPS capable" OpenSSL combination to make it possible to
>> have a system wide "FIPS mode" capability, but that presumes that
>> the system maintainer (i.e. OS distribution maintainer) has done
>> the review and modification of each application that uses
>> cryptography to make sure it is compatible with the many
>> restrictions of FIPS mode.
> 
> Yes, I understand the concern.  Does this mean that the FIPS checks
> will be done today on OpenSSL library startup w/o the need for an
> application to use FIPS_mode_set() ?  I'm asking since the OpenSSL
> FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and
> FIPS_selftest()).  Might have to do with your comment below.

The user guide documents that correctly. For the OpenSSL FIPS Object
Module 2.0 (#1747) the FIPS mode of operation is enabled with
FIPS_mode_set(). There is no "library startup"; you keep confusing past
validations with new ones.

Note that we would update that existing module to comply with the new
I.G. 9.10 guidance, but that falls in the class of changes that are not
permitted under the "change letter" update process (similarly, we
weren't allowed to update the module to address security vulnerabilities
such as "Lucky 13").

>> That is indeed the assumption: that commercial versions of RH and
>> SuSE have modified all impacted OSS applications to operate in FIPS
>> mode. If they haven't they are deceiving their customers and the
>> U.S. government.
> 
> I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago,
> though.
> 
>> Please read the first two sentences on that web page, right at the
>> top.
> 
> OK!  Regarding the second sentence :) ... what is the current status
> ? 

We have not done any validations that satisfy the various new
requirements introduced in late 2013 and early 2014. New validations are
very expensive, in dollars, time, and grief, and we don't have the
necessary financial backing.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Hostname validation

[Viktor Dukhovni]

On Tue, Jan 27, 2015 at 04:18:49PM +0300, Serj wrote:

> I didn't find docs on such functions as SSL_get0_param

As I mentioned, this function should be documented, but is not yet.

> Why there is no corresponding functions as SSL_set0_param in your code?
> Where can I found documentation on functions operating with params?

The documentation for these functions is not yet written.  The way
I would set SSL verification parameters is to obtain the parameter
handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(),
and use the various X509_VERIFY_PARAM_mumble() functions to tweak
the parameter object in place.

Parameters that apply to all connections should be set at the
SSL_CTX level, when the context is created.  Specifics like
hostnames, ... should be set for each connection via the SSL
object.

> But there is no any description how SSL_CTX_set1_param works!
> Does it clear all previous flags on CTX or "ORing" with them?
> And there are no any docs on "GET" params functions!

Yes, these need (more) documentation.

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

Re: [openssl-users] Using FIPS mode and modifying apps

[jonetsu]

"Steve Marquess" wrote on 01/27/15 09:18:
Thank you (and Tom) for your comments - much appreciated.

> Tom Francis nailed the answer to this one. We did design the FIPS module
> + "FIPS capable" OpenSSL combination to make it possible to have a
> system wide "FIPS mode" capability, but that presumes that the system
> maintainer (i.e. OS distribution maintainer) has done the review and
> modification of each application that uses cryptography to make sure it
> is compatible with the many restrictions of FIPS mode.

Yes, I understand the concern.  Does this mean that the FIPS checks will be 
done today on OpenSSL library startup w/o the need for an application to use 
FIPS_mode_set() ?  I'm asking since the OpenSSL FIPS User Guide 2.0 only 
mentions using FIPS_mode_set() (and FIPS_selftest()).  Might have to do with 
your comment below.
 
> That is indeed the assumption: that commercial versions of RH and SuSE
> have modified all impacted OSS applications to operate in FIPS mode. If
> they haven't they are deceiving their customers and the U.S. government.

I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, though.
 
> Please read the first two sentences on that web page, right at the top.

OK!  Regarding the second sentence :) ... what is the current status ?  Is 
OpenSSL transparently executing FIPS checks when in FIPS mode ?  And, why would 
there be any validation (as opposed to functional tests) to be done since these 
checks are the same as they were before I presume, just done automatically this 
time around.

Regards.



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

Re: [openssl-users] Hostname validation

[Serj]

Hi, Viktor.

I have some questions.
I didn't find docs on such functions as SSL_get0_param
Why there is no corresponding functions as SSL_set0_param in your code?
Where can I found documentation on functions operating with params?

I found only this code:
  X509_VERIFY_PARAM *param;
  param = X509_VERIFY_PARAM_new();
  X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK);
  SSL_CTX_set1_param(ctx, param);
  X509_VERIFY_PARAM_free(param);

here: https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html

But there is no any description how SSL_CTX_set1_param works! Does it clear all 
previous flags on CTX or "ORing" with them?
And there are no any docs on "GET" params functions!

For example, like docs on 
SSL_CTX_set_options,SSL_CTX_get_option,SSL_set_options,SSL_get_options.


--
Best Regards,

Serj

25.01.2015, 20:59, "Viktor Dukhovni" :
> On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote:
>>  What is the best way to make hostname validation?
>>
>>  1. http://wiki.openssl.org/index.php/Hostname_validation
>>  2. X509_check_host that was added in OpenSSL 1.1.0.
>
> The X509_check_host() interface is also available in OpenSSL 1.0.2
> released a few days ago
>
> https://www.openssl.org/docs/crypto/X509_check_host.html
>
> (the documentation should be updated to note the earlier availability).
>
> Starting with 1.0.2, you can also ask OpenSSL to automatically
> perform hostname checks during the SSL handshake on the application's
> behalf:
>
> https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html
> https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html
> https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html
> https://www.openssl.org/docs/ssl/SSL_set_verify.html
>
> Sadly, we're still lacking documentation of SSL_get0_param() which
> is needed for a complete SSL hostname check recipe:
>
> const char *servername;
> SSL *ssl;
> X509_VERIFY_PARAM *param;
>
> servername = "www.example.com";
> ssl = SSL_new(...);
> param = SSL_get0_param(ssl);
>
> /* Enable automatic hostname checks */
> X509_VERIFY_PARAM_set_hostflags(param, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
> X509_VERIFY_PARAM_set1_host(param, servername, 0);
>
> /* Configure a non-zero callback if desired */
> SSL_set_verify(ssl, SSL_VERIFY_PEER, 0);
>
> /*
>  * Establish SSL connection, hostname should be checked
>  * automatically test with a hostname that should not match,
>  * the connection will fail (unless you specify a callback
>  * that returns despite the verification failure.  In that
>  * case SSL_get_verify_status() can expose the problem after
>  * connection completion.
>  */
>  ...
>>  I don't know does the first one support wildcards or no! Seems
>>  to be: how does Curl_cert_hostcheck work - is the answer, but I
>>  don't know how it works.
>
> Wildcard support is configured via the flags documented for X509_check_host(),
> the two most frequently useful are:
>
> X509_CHECK_FLAG_NO_WILDCARDS
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS
>
> --
> Viktor.
> ___
> 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] Using FIPS mode and modifying apps

[Steve Marquess]

On 01/26/2015 06:21 PM, jone...@teksavvy.com wrote:
> On Fri, 16 Jan 2015 10:16:48 -0500
> Steve Marquess  wrote:
> 
>> On 01/15/2015 05:52 AM, Marcus Meissner wrote:
> 
>>> On Linux usually triggered by /proc/sys/crypto/fips_enabled
>>> containing "1" or the environment variable
>>> OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and
>>> Redhat, which do not use the container blob).
> 
>> That is (presumably) true for the proprietary RH and SUSE distros,
>> not so for the open source based OpenSSL FIPS Object Module or other
>> Linux distros.
> 
> I'm afraid it does not come across clear to me.  So, maybe the
> following pondering is relevant - or not.  Basically, I'm looking at
> how to integrate a FIPS-enabled OpenSSL that will be used by some
> common Open Sources applications, as well as a 3rd party application
> (with source code provided).

Tom Francis nailed the answer to this one. We did design the FIPS module
+ "FIPS capable" OpenSSL combination to make it possible to have a
system wide "FIPS mode" capability, but that presumes that the system
maintainer (i.e. OS distribution maintainer) has done the review and
modification of each application that uses cryptography to make sure it
is compatible with the many restrictions of FIPS mode.

> So, does your comment mean that the paying versions of Red
> Hat and SuSE (proprietary) have open source applications modified to at
> least include the FIPS_mode_set() call ?  Why would these releases be
> different in FIPS SSL 'power-up' POST checks when compared to regular
> free releases ?

That is indeed the assumption: that commercial versions of RH and SuSE
have modified all impacted OSS applications to operate in FIPS mode. If
they haven't they are deceiving their customers and the U.S. government.

Note that such modifications are non-trivial for some applications, for
instance OpenSSH.

> If I compare with GnuTLS that our product also uses, and with which it
> will also go to certification, its FIPS mode is completly transparent,
> with FIPS checks done on library load.

Can't help you there as I know nothing of GnuTLS. But, applications
using GnuTLS will face exactly the same problem; if they were not
designed or modified to operate in FIPS mode you're probably going to
have undesirable outcomes.

> Based on the discussion in 'The I.G. 9.5 Issue', I took a look at
> 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic
> Module Validation Program', January 15 2015 release.  In section 9.10
> it states:...

Please read the first two sentences on that web page, right at the top.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users