On 11/09/17 14:02, Илья Шипицин wrote: > > > 2017-09-11 16:54 GMT+05:00 Илья Шипицин <chipits...@gmail.com > <mailto:chipits...@gmail.com>>: > > > > 2017-09-11 16:45 GMT+05:00 Jan Just Keijser <janj...@nikhef.nl > <mailto:janj...@nikhef.nl>>: > > Hi, > > On 11/09/17 13:22, Илья Шипицин wrote: > > Hello, > > is someone actually using "tls-verify" in production ? > we tried to implement additional certificate check using > tls-verify > > > while it works in general, in case when it hits "exit 1", it > look like a timeout from client point of view. it is not any > good > > > do you mean that when a client is denied access (i.e. the > tls-verify script exits 1 on the server) that the client sees > this as a timeout? that is "normal" behaviour, as the server > does not tell the client *WHY* access is refused - it simply > stop responding to a client that does not pass > authentication/authorization. The client will not hear from the > server, and will time out after a specified interval. This is > actually the most secure way to do things, as a rogue client > cannot DoS a server this way. > > > I'd say it depends. > > we run a lot of openvpn-gui with real people sitting in front of > them, from their point of view it "oh, it does not work! fix it!" > in out case better UX is to deliver proper reason to the client > > for someone maybe the better UX is to keep silence > > > > what is wrong with timeout is endless retry. > there's no way to pass authentication once it failed, so why does client > have to retry ?
User-friendliness and security seldom walks hand-in-hand. As this friendliness provides enough information fragments for an attacker to figure out "I need to try something else". A non-responding server gives no clues. It can be a crappy server or it can be access denied; the attacker doesn't know - thus making it harder to figure out what to do next. The client will by default try to reconnect, because that is what it in most cases is told to do when the server is unresponsive. And since this happens with many seconds in between, a single client will not attempt to DoS a server by mistake by retrying in a too tight loop. A failed authentication is a failed authentication. Thus UX client front-ends could treat this silence like that - but also account for other types of connectivity issues. If it should try to reconnect or not, well, that's entirely up to the configuration file. There is --single-session which can be used to control this. But for servers running OpenVPN clients, retrying indefinitely at regular intervals may just as well be valuable; if it is an issue which is temporary. Then these clients would reconnect once everything is back online again on the server side. -- kind regards, David Sommerseth OpenVPN Technologies, 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
