2017-10-06 14:42 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:
> On 06/10/17 11:37, Илья Шипицин wrote:
> >
> >
> > 2017-10-06 14:11 GMT+05:00 David Sommerseth
> > <open...@sf.lists.topphemmelig.net
> > <mailto:open...@sf.lists.topphemmelig.net>>:
> >
> > On 06/10/17 11:02, Илья Шипицин wrote:
> > >
> > >
> > > 2017-10-06 13:43 GMT+05:00 David Sommerseth
> > > <open...@sf.lists.topphemmelig.net
> > <mailto:open...@sf.lists.topphemmelig.net>
> > > <mailto:open...@sf.lists.topphemmelig.net
> > <mailto:open...@sf.lists.topphemmelig.net>>>:
> > >
> > > On 06/10/17 08:58, Илья Шипицин wrote:
> > > > Hello,
> > > >
> > > > I used to run openvpn in login/password mode for years.
> > > > now, I'm getting working certificate setup.
> > > >
> > > >
> > > > what I found strange about revoked certificates ... from
> > client point of
> > > > view it looks like any other "tls key negotiation timeout"
> > > >
> > > > is there a way to signal user "hey, you key is revoked" ?
> > >
> > > Nope, not in the current implementation and design. To be
> able to
> > > signal that, you need to have some established a connection.
> > And that
> > > cannot be done unless the client provides a valid
> > certificate. If the
> > > certificate is invalid (issued by wrong CA, expired, revoked),
> the
> > > server just drops the ball.
> > >
> > > Perhaps we could look into adding a new OPCODE which could
> signal
> > > connection errors. But that needs to be very carefully
> > implemented so
> > > we don't open up for various DoS attacks or more effective
> > bruteforce
> > > attacks. Such a message would also need to be verifiable too,
> > otherwise
> > > it would be too easy for a filtering firewall or gateway to
> > just respond
> > > back with such a rejection message instead of passing the
> packet
> > > further; effectively shutting down clients with the wrong
> > presumptions.
> > > Plus it needs to be implemented in the OpenVPN 3 Core library
> > as well
> > > (which OpenVPN Connect clients uses). So this isn't even a
> > quick-fix.
> > >
> > > But I would also be very cautious about providing reasons back
> to
> > > clients though. For all these various invalid certificate
> > scenarios we
> > > definitely should not give a too fine grained explanation.
> > IMO, only a
> > > "Invalid certificate" message should be considered.
> > >
> > >
> > > taking all the above into account, I would compare things in
> > "https" world.
> > > both "server cert error" and "client cert error" are handled in
> > somewhat
> > > friendly way (without considering such additional information as a
> > > security breach)
> >
> > But the OpenVPN wire protocol is anything similar to standard SSL/TLS
> > protocols. The SSL/TLS protocol is wrapped into an OpenVPN
> container,
> > where the SSL/TLS specifics packets happens in a limited set of of
> the
> > OpenVPN wire protocol, most commonly referred to as the control
> channel.
> >
> > In addition, what happens when you try to use a revoked *client*
> > certificate when connecting to an HTTPS server demanding client
> > certificates to be present?
> >
> >
> > 403
> >
> > (with customizable error message)
> Really? That shouldn't be possible, as you don't have an established
> TLS connection to provide the HTTP 403 response. Because the server
> should reject the connection as the *client* certificate is invalid.
>
I did test on IIS with "certificate required", when you connect without
cert, you can see 403.
ok, I'll test with revoked cert as well
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN, Inc
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
