Re: [Openvpn-devel] proper configuring of "tls-verify"

[Steffan Karger]

Hi,

On 11-09-17 15:23, Илья Шипицин wrote:
> 2017-09-11 17:30 GMT+05:00 David Sommerseth
>  >:
> 
> On 11/09/17 14:02, Илья Шипицин wrote:
> >
> >
> > 2017-09-11 16:54 GMT+05:00 Илья Шипицин  
> > >>:
> >
> >
> >
> > 2017-09-11 16:45 GMT+05:00 Jan Just Keijser  
> > >>:
> >
> > 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

As JJK already posted, this is indeed by design.  I haven't been around
long enough to know the exact reasons behind it.  My guess is that it's
partially a KISS thing - if we immediately abort the connection, we do
not have to worry about corner cases.  If we allow the connection to go
on, to e.g. send TLS alerts, we need to be more careful that we do not
allow anything else accident by too.

But judging from what I do know, I think it might be worth it to rely on
tls-auth/tls-crypt (and hopefully soon tls-crypt-v2) for DoS protection,
and improve the user experience by letting TLS send it's 'connection
rejected' and 'alert' messages.  But that would require some careful
thinking and code review and will certainly not happen before 2.5.

Finally, to preven confusion: this is not only about 'tls-verify', but
about TLS connection failures in general.  A 'tls-verify' failure should
behave just as any other TLS failure, and right now that is aborting the
connection immediately.

-Steffan

--
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

Re: [Openvpn-devel] proper configuring of "tls-verify"

[Илья Шипицин]

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 Илья Шипицин  > >:
> >
> >
> >
> > 2017-09-11 16:45 GMT+05:00 Jan Just Keijser  > >:
> >
> > 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

Re: [Openvpn-devel] proper configuring of "tls-verify"

[Arne Schwabe]

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 Илья Шипицин > >:
>>
>>
>>
>> 2017-09-11 16:45 GMT+05:00 Jan Just Keijser > >:
>>
>> 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

Re: [Openvpn-devel] proper configuring of "tls-verify"

[David Sommerseth]

On 11/09/17 14:02, Илья Шипицин wrote:
> 
> 
> 2017-09-11 16:54 GMT+05:00 Илья Шипицин  >:
> 
> 
> 
> 2017-09-11 16:45 GMT+05:00 Jan Just Keijser  >:
> 
> 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

Re: [Openvpn-devel] proper configuring of "tls-verify"

[Илья Шипицин]

2017-09-11 16:54 GMT+05:00 Илья Шипицин :

>
>
> 2017-09-11 16:45 GMT+05:00 Jan Just Keijser :
>
>> 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 ?


>
>
> while I think "exit 1" will not be the most common case (it is rather an
> exception), we'd like to deliver better UX to people
>
>
>
>>
>> HTH,
>>
>> JJK
>>
>>
>
--
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

Re: [Openvpn-devel] proper configuring of "tls-verify"

[Илья Шипицин]

2017-09-11 16:45 GMT+05:00 Jan Just Keijser :

> 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


while I think "exit 1" will not be the most common case (it is rather an
exception), we'd like to deliver better UX to people



>
> HTH,
>
> JJK
>
>
--
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

Re: [Openvpn-devel] proper configuring of "tls-verify"

[Jan Just Keijser]

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.


HTH,

JJK


--
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

[Openvpn-devel] proper configuring of "tls-verify"

[Илья Шипицин]

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

Cheers,
Ilya Shipitsin
--
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