Re: [openssl-users] Hostname validation in OpenSSL 1.1.0

2017-04-04 Thread Viktor Dukhovni

> On Apr 4, 2017, at 5:57 PM, Hajjar, Alain (US)  
> wrote:
> 
> I am looking for confirmation regarding the hostname validation
> implementation in OpenSSL 1.1.0. Is the example code at
> https://wiki.openssl.org/index.php/Hostname_validation the correct
> way to do hostname validation with both 1.1.0 and 1.0.2? 

Looks reasonable.

> Specifically, in order for OpenSSL 1.1.0 to automatically perform
> hostname checks, does the calling application need to use both
> X509_VERIFY_PARAM_set1_host (with the expected DNS hostname) and
> SSL_set_verify (with SSL_VERIFY_PEER) as is the case for
> OpenSSL 1.0.2?

Setting the hostname causes hostname checks to happen, regardless
of the SSL verification mode.  Applications that want the SSL
handshake to be aborted on verification failure can set SSL_VERIFY_PEER.
Applications that want to be able to continue despite verification failure,
can set SSL_VERIFY_NONE, and check the results of SSL_get_verify_result()
as described in:

https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_verify.html
https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_verify.html

Postfix (for which I maintain the TLS stack) uses the SSL_VERIFY_NONE
approach, completes the handshake, and politely disconnects from the
server at the SMTP layer (sends "QUIT") when server authentication
fails.  Other applications may prefer to abort the handshake with a
suitable TLS-layer alert.

-- 
Viktor.

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


[openssl-users] Hostname validation in OpenSSL 1.1.0

2017-04-04 Thread Hajjar, Alain (US)
Hello,

I am looking for confirmation regarding the hostname validation
implementation in OpenSSL 1.1.0. Is the example code at
https://wiki.openssl.org/index.php/Hostname_validation the correct way to do
hostname validation with both 1.1.0 and 1.0.2?

Specifically, in order for OpenSSL 1.1.0 to automatically perform hostname
checks, does the calling application need to use both
X509_VERIFY_PARAM_set1_host (with the expected DNS hostname) and
SSL_set_verify (with SSL_VERIFY_PEER) as is the case for OpenSSL 1.0.2?

Thank you.

Alain

Alain Hajjar
mobile +1 240 330 3754
direct +1 443 884 6687

CyberPoint International
621 East Pratt Street, Suite 400

Baltimore MD 21202-3196

phone +1 410 779 6700

www.cyberpointllc.com 




If you believe you received this e-mail in error, please notify the sender
immediately, delete the e-mail from your computer and do not copy or
disclose it to anyone else.

The information in this email constitutes the proprietary information of
Cyber Point International, LLC, and should be accessed only by the
individual to whom it is addressed. The information in this email and any
attachments may not be used, copied or disclosed without the consent of
CyberPoint. CyberPoint is not responsible for any damages caused by your
unauthorized use of the materials in this email.




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

2017-04-04 Thread Benjamin Kaduk via openssl-users
On 04/04/2017 10:39 AM, Viktor Dukhovni wrote:
>> On Apr 4, 2017, at 10:41 AM, Short, Todd via openssl-users 
>>  wrote:
>>
>> Ben Kaduk:
>>
>> Do we know the values that are being passed to SSL_CTX_set_verify_depth()
>> match the -verify_depth argument, or do they differ?  If they differ, do
>> identical arguments to the function behave the same in 1.1.0 and 1.0.2?
> The "-verify_depth" argument to verify(1) just calls 
> SSL_CTX_set_verify_depth(3)
> with the given depth value.  In OpenSSL 1.1.0, this sets a limit on the
> intermediate CA count and returns sensible errors when the depth limit is
> exceeded.

(Pedantic note: the apps call X509_VERIFY_PARAM_set_depth() directly,
and s_client goes on to use SSL_CTX_set1_param().)  But the answer to
the actual question asked is the same, the depth argument used for
verification is just the one passed on the command line.  Behavior
differences stem in the library.

>> Viktor:
>>
>> What we’re getting at here, is that this appears to be a potentially
>> significant behavioral change. We want to understand it better.
> The code no longer returns misleading errors, and is better documented
> in verify(3), but it seems I missed additional requisite documentation
> updates in SSL_CTX_set_verify_depth(3).  It would be great if someone
> volunteered to complete the documentation update.
>

I have it on my list of things to look at if there is free time
available (which is hardly guaranteed).

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


Re: [openssl-users] [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

2017-04-04 Thread Viktor Dukhovni

> On Apr 4, 2017, at 10:41 AM, Short, Todd via openssl-users 
>  wrote:
> 
> Ben Kaduk:
> 
> Do we know the values that are being passed to SSL_CTX_set_verify_depth()
> match the -verify_depth argument, or do they differ?  If they differ, do
> identical arguments to the function behave the same in 1.1.0 and 1.0.2?

The "-verify_depth" argument to verify(1) just calls SSL_CTX_set_verify_depth(3)
with the given depth value.  In OpenSSL 1.1.0, this sets a limit on the
intermediate CA count and returns sensible errors when the depth limit is
exceeded.

> Viktor:
> 
> What we’re getting at here, is that this appears to be a potentially
> significant behavioral change. We want to understand it better.

The code no longer returns misleading errors, and is better documented
in verify(3), but it seems I missed additional requisite documentation
updates in SSL_CTX_set_verify_depth(3).  It would be great if someone
volunteered to complete the documentation update.

-- 
Viktor.

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


Re: [openssl-users] [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

2017-04-04 Thread Short, Todd via openssl-users
Ben Kaduk:

Do we know the values that are being passed to SSL_CTX_set_Verify_depth() match 
the -verify_depth argument, or do they differ?
If they differ, do identical arguments to the function behave the same in 1.1.0 
and 1.0.2?

Viktor:

What we’re getting at here, is that this appears to be a potentially 
significant behavioral change. We want to understand it better.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Apr 3, 2017, at 4:43 PM, Viktor Dukhovni 
> wrote:


On Apr 3, 2017, at 4:26 PM, Benjamin Kaduk 
> wrote:

There was a fair amount of churn in x509_vfy.c with the inclusion
of the DANE stuff and whatnot, so it's not immediately clear to me
when this change actually happened.  I think there are good
arguments for the current 1.1.0 behavior and it doesn't really make
sense to try to change back to the historical behavior, but it would
be good to know when the change actually happened and that it is/was
a known change.  Ideally we could also document the different
behavior between 1.0.x and 1.1.0 better; any thoughts about where to
do so?

https://www.openssl.org/docs/man1.1.0/apps/verify.html

  -verify_depth num

Limit the certificate chain to num intermediate CA certificates.
A maximal depth chain can have up to num+2 certificates, since
neither the end-entity certificate nor the trust-anchor
certificate count against the -verify_depth limit.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify_depth.html

SSL_CTX_set_verify_depth() sets the maximum depth for the
certificate chain verification that shall be allowed for ctx.
(See the BUGS section.)
...
BUGS

The certificate verification depth set with SSL[_CTX]_verify_depth()
stops the verification at a certain depth. The error message
produced will be that of an incomplete certificate chain and
not X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected.

The 1.0.2 behaviour was under-documented and somewhat broken.  This
was fixed in 1.1.0.


Unfortunately, the SSL_CTX_set_verify_depth(3) was not brought up to date,
contributes welcome:

  https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_verify_depth.html

--
Viktor.

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

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


Re: [openssl-users] TLS 1.3

2017-04-04 Thread Thiago Arrais
Thank you for the reply, Matt.

Let's talk on openssl-dev.

On Tue, Apr 4, 2017 at 9:33 AM Matt Caswell  wrote:

>
>
> On 04/04/17 12:55, Thiago Arrais wrote:
> > I'm interested in contributing to TLS 1.3 support. Is it "done" yet?
> > Where do I start? Can anyone point me in the right direction?
> >
> > (BTW, total newbie here. Never contributed to OpenSSL.)
>
> Mostly TLSv1.3 support is already done. You can try it out in the git
> master branch by configuring with "enable-tls1_3".
>
> I say "mostly" because the spec itself is not finalised. The OpenSSL
> implementation is based on draft-19, but we are expecting draft-20
> sometime soon which has a few minor technical changes. There are also a
> list of optional extra features (i.e. not required for compliance) that
> I consider "nice-to-have" and aren't done yet (e.g. configurable record
> layer padding, ffdhe groups, configurable number of key_shares etc).
>
> Matt
>
> P.S. This post is probably better directed at the openssl-dev email list
> as it is about the development of OpenSSL itself.
>
> --
> 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] TLS 1.3

2017-04-04 Thread Matt Caswell


On 04/04/17 12:55, Thiago Arrais wrote:
> I'm interested in contributing to TLS 1.3 support. Is it "done" yet?
> Where do I start? Can anyone point me in the right direction?
> 
> (BTW, total newbie here. Never contributed to OpenSSL.)

Mostly TLSv1.3 support is already done. You can try it out in the git
master branch by configuring with "enable-tls1_3".

I say "mostly" because the spec itself is not finalised. The OpenSSL
implementation is based on draft-19, but we are expecting draft-20
sometime soon which has a few minor technical changes. There are also a
list of optional extra features (i.e. not required for compliance) that
I consider "nice-to-have" and aren't done yet (e.g. configurable record
layer padding, ffdhe groups, configurable number of key_shares etc).

Matt

P.S. This post is probably better directed at the openssl-dev email list
as it is about the development of OpenSSL itself.

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


[openssl-users] TLS 1.3

2017-04-04 Thread Thiago Arrais
I'm interested in contributing to TLS 1.3 support. Is it "done" yet? Where
do I start? Can anyone point me in the right direction?

(BTW, total newbie here. Never contributed to OpenSSL.)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] OCSP Responder Running on Localhost using the Source Code..!

2017-04-04 Thread Jakob Bohm

The code for the command "openssl xyz" is usually in the source
file apps/xyz.c .

So the example OCSP responder is probably in the file apps/ocsp.c .

On 04/04/2017 09:04, RajatRokade wrote:

Hi..
I want to create an OCSP responder running on my local machine to avoid the
requirement of internet connection.I tired using the command line approach
to set up a new CA,build database,run the responder on the localhost and
finally query the OCSP responder. I was able to query the server and get the
response back with the status the certificate.

I want to build the responder using C#. As a start i tried exploring the
different OCSP options using command line approach. I am trying out the same
with ManagedOpenSSl c# wrapper. In that wrapper no API's related to OCSP are
present so i thought i will have to write the wrapper for OCSP on my own.

I am not able to understand how do i use the available openssl source code
which is present in C language to implement the OCSP responder function.

Please help me with this as i am very new to openssl and OCSP concepts.




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


[openssl-users] OCSP Responder Running on Localhost using the Source Code..!

2017-04-04 Thread RajatRokade
Hi..
I want to create an OCSP responder running on my local machine to avoid the
requirement of internet connection.I tired using the command line approach
to set up a new CA,build database,run the responder on the localhost and
finally query the OCSP responder. I was able to query the server and get the
response back with the status the certificate.

I want to build the responder using C#. As a start i tried exploring the
different OCSP options using command line approach. I am trying out the same
with ManagedOpenSSl c# wrapper. In that wrapper no API's related to OCSP are
present so i thought i will have to write the wrapper for OCSP on my own.

I am not able to understand how do i use the available openssl source code
which is present in C language to implement the OCSP responder function. 

Please help me with this as i am very new to openssl and OCSP concepts.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/OCSP-Responder-Running-on-Localhost-using-the-Source-Code-tp70327.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users