2017-09-11 17:30 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:
> 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.
>
an attacker can brute force a password, for example.
but what do you mean "to try next" in case of ssl certificate ?
>
> 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
>
if retry might be successful, yes.
if authentication failed - no
> 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
>
>
>
------------------------------------------------------------------------------
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
