On 05/04/17 14:36, Simon Matter wrote: >> On 05/04/17 09:31, Steffan Karger wrote: >>> Hi, >>> >>> On 05-04-17 08:57, Gert Doering wrote: >>>> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote: >>>>> I've attached v2 now which works without any config change: >>>> [..] >>>>> I prefer this version as it allows everybody to profit from it without >>>>> touching any config files. >>>> >>>> I can see the reasoning, but 25% feels a bit on the high side :-) - so >>>> let the ratholing begin what the number should be. >>>> >>>> Steffan, any views from the crypto side of things? >>> >>> Not really. I think the feature makes sense, and I like that this will >>> only *substract* from the set time (so not exceed any set limits). >>> >>> (And I agree that 25% feels on the high side - my gut says somewhere >>> around 10%, but I have no analysis to show why that would be better. >>> I'll leave picking that number to you.) >> >> The default is 60 minutes. With 25% that means a time window of 15 >> minutes, so reneg-sec will occur between 45-60 minutes. >> >> I see this can be too much for some sites, and perhaps too little on >> sites which have many users. With 10%, the reneg-window is reduced to >> 54-60 minutes. For larger sites, this is most likely too small of a >> window - though far better than everyone at "exactly" 60 minutes. >> >> But I am also wondering if this randomness should only occur on the >> first renegotiation. >> >> If you have a 6 minutes time window and 100 connected clients, there is >> a big chance that at some point the randomness will cause a similar >> congestion again, as multiple clients to have the same delay. With 25% >> that chance is lower, but the chance increases again with more clients. >> >> So what if this randomness instead only occurs on the _first_ >> negotiation and then respect the --regneg-sec setting? Then clients >> will somewhat spread out and then keep a certain predictable >> renegotiation load. And if using 17%, you get a time window of roughly >> 10-11 minutes where renegotiation happens. With 100 clients, that means >> roughly (with a theoretical, ideal and even spread) 10 clients per >> minute. Which is more reasonable. With 200 clients, it is still >> getting crowded but not too bad. >> >> But all that said ... I think it would be wise to have an optional >> argument to --reneg-sec (in addition to the 'sec' argument we have >> today) which can be used to further open or close this time window. >> Larger sites will most likely want a larger time window than smaller ones. >> >> Btw ... is --reneg-sec pushable? (Too lazy to check the code, man page >> says "no"). If not, it would probably be a good idea to enable that. > > As I understand it client and server have 60 min. by default. Whatever is > configured, the smaller value wins. That means, bad clients can set their > reneg-sec to very low values and trash the server on the other end. From > the server side this looks more or less like a DDOS.
That's possible today as well .... so I don't fully follow why this is
interesting in regards to the randomness or push-ability of --reneg-sec.
This can be pulled much further. If you have an OpenVPN server on TCP,
even that is susceptible to D/DoS attacks too, where even
--tls-{auth,crypt} won't protect you. For UDP, --tls-{auth,crypt} does
provide a nice barrier - unless the attacker(s) have access to that.
There's not even a need to complete the full TLS negotiation.
The point is, if I ever wanted to D/DoS an OpenVPN server, I'd partially
implement the OpenVPN protocol in an attack tool to start and perhaps
complete the TLS handshake just to start over again. This would be far
more efficient than to use OpenVPN itself. This can be multi-thread,
kicking off thousands of connections in parallel, and then deploy that
on a variety of VMs around the world. Have 64 such VMs initiating 1024
TCP connections each to any TCP based server in a loop - and the port
pool on the server is exhausted.
So I doubt any reasonable client would really knowingly set
--reneg-sec 1 just for the bloody fun of it. The tunnel would be close
to useless. Unless you're a clueless, bored script kiddie with no
imagination (yes, I know, there's plenty of them too).
As a mitigation to such attacks, it is possible to deploy some firewall
rules (see the iptables recent module for example) to restrict how often
IP address may initiate connections to the server.
Bottom line is ... I don't see D/DoS being a real issue, especially not
in regards to --reneg-sec.
> In our environment we have set reneg-sec=0 on all clients because we want
> the server to have control over it. That's fine because we have only
> trusted clients. Making it pushable could be a solution to overwrite bad
> settings in clients.
Yes, I think this makes sense. If the client don't want it - it is
possible to deploy a --pull-filter in the local client configuration.
> A more radical solution was to just remove the option on the client side.
Probably not going to happen. This implies that the client trust the
server. While that is reasonable in some configurations (corporate or
private servers, fpr exampe), using a commercial VPN provider to avoid
Geo-blocking (or whatever reason they have) - this assumption might not
be equally true.
Plus it would break lots of already existing configurations. We could
discuss making it a NOP on the client side. But that can be more painful
to tackle; the exact same option parser in OpenVPN is used for all
command line arguments, configuration files, CCD files and pushed
options - and I might have forgotten a few more handfuls of users.
--
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
