|
|
Jason Keltz wrote:
> Hi..
>
> I have a question about the "replay protection" with OpenVPN. As I
> understand it, the OpenVPN server is not happy seeing the time of a
> client change backwards in time, but it would be fine with the client
> time changing forward in time. What I am wondering is how OpenVPN deals
> with time changes due to say, daylight savings time where all the
> connected clients would suddenly lose, say, an hour? (of course the
> server would lose time as well). What would happen with connected clients?
>
> Also -- How often does OpenVPN check for the time change? I recently
> found a problem with a client connecting to my VPN that was running
> ntpdate AFTER the startup of the VPN. The client did initially connect,
> but after about 20 seconds would get disconnected...
>
> Thanks for any help you can provide..
>
> Jason.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>
We do have daylight savings here in brasil. I do update the time of the
server and all my clients with ntpdate. Even when openvpn is running. I
do have an script that do a ntpdate every hour. This script is running
hourly. I never had this problem that you are reporting. I believe that
you are using either static keys or some cipher algo in the CFB or OFB
mode. From the OpenVPN manual:
--no-replay
Disable OpenVPN's protection against replay attacks.
Don't use this option unless you are prepared
to make a tradeoff of greater efficiency in exchange for
less security.
OpenVPN provides datagram replay protection by default.
Replay protection is accomplished by tagging each
outgoing datagram with an identifier that is
guaranteed to be unique for the key being used. The peer
that receives the datagram will check for
the uniqueness of the identifier. If the identifier was
already received in a previous datagram,
OpenVPN will drop the packet. Replay protection is
important to defeat attacks such as a SYN flood
attack, where the attacker listens in the wire,
intercepts a TCP SYN packet (identifying it by the
context in which it occurs in relation to other packets),
then floods the receiving peer with
copies of this packet.
OpenVPN's replay protection is implemented in slightly
different ways, depending on the key manage-
ment mode you have selected.
In Static Key mode or when using an CFB or OFB mode
cipher, OpenVPN uses a 64 bit unique identifier
that combines a time stamp with an incrementing sequence
number.
When using TLS mode for key exchange and a CBC cipher
mode, OpenVPN uses only a 32 bit sequence
number without a time stamp, since OpenVPN can guarantee
the uniqueness of this value for each key.
As in IPSec, if the sequence number is close to wrapping
back to zero, OpenVPN will trigger a new
key exchange.
To check for replays, OpenVPN uses the sliding window
algorithm used by IPSec.
I think that if you use TLS, and a cipher in CBC mode (i suggest
AES-256-CBC), you won't have these problems anymore.
My regards,
--
Giancarlo Razzolini
Linux User 172199
Moleque Sem Conteudo Numero #002
Slackware Current
Snike Tecnologia em Informática
4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Attachment:
signature.asc
Description: OpenPGP digital signature
|