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.
-- kind regards, David Sommerseth OpenVPN, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
