Am 11.09.17 um 14:30 schrieb David Sommerseth: > 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. >
Also you can limit the number of unsucessfull retries in OpenVPN with the connnect-retry option. Arne ------------------------------------------------------------------------------ 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
