OVPN HMAC authentication switching from SHA1 to SHA256

[maxbraketorque]

I've had a site-to-site OVPN setup enabled since ~2020. At the time, I used SHA1 for HMAC authentication, and I have custom certificates made up with that configuration. I had assumed that if I wanted to switch to SHA256, then I would have to make up new certs, but I tried this morning using SHA256, and the link went up fine.

So I guess that the VPN server certificate values are not dependent on HMAC authentication encoding selection?

Also, I've always assumed that "auth digest" on the client side is the same thing as "HMAC authentication" on the server side. But since the names are different, maybe they are different things?

 

[eibgrad]

Options as described in the GUI typically use more descriptive naming than the underlying option as defined in the config file, for obvious reasons. And nothing says each side of the connection (client and server) necessarily will describe them the same.

In this case, each side is using the auth option for HMAC authentication, where the value specifies an algorithm to be used in authenticating the data channel packets. It has nothing to do w/ your certs or keys. It's primarily intended to prevent (D)DoS attacks by killing off bogus connection attempts as soon as possible, rather than having the client go through the entire TLS handshake (which consumes significant resources) and only then finding the client isn't legit. For that reason, it's NOT even a required setting, but just a recommendation. And it's the server side that decides if and when it will be required.

 

[maxbraketorque]

Thanks! If I change the TLS authentication method, do I have to generate new certs?

 

[eibgrad]

Thanks! If I change the TLS authentication method, do I have to generate new certs?

No. auth and tls-auth are simply a means to encrypt and authenticate individual packets. The former is for data channel packets, the latter for control channel packets. They provide an *additional* layer of security. What's in those packets such as certs, keys, whatever, is of no concern. Unless a packet successfully navigates through the auth/tls-auth process, it gets dropped. IOW, these settings act as a gateway to prevent any further access unless and until you prove you are legit. They tell you NOTHING about whether any further access will still be permitted due to certs/keys, which manage their own separate authentication.

Again, it's just a quick and dirty means to flush out bad actors as soon as possible, rather than assuming all is well and only to find out later there's a problem.

 

[RMerlin]

Note that with a GMC cipher, you don't need an HMAC.

 

[maxbraketorque]

Note that with a GMC cipher, you don't need an HMAC.

GCM I guess? Why not needed with it?

 

[RMerlin]

GCM I guess? Why not needed with it?

Because the authentication is done by the cipher itself.

 

[maxbraketorque]

If I'm using GCM (I am), is there value to having tls control channel security enabled?

 

[eibgrad]

If I'm using GCM (I am), is there value to having tls control channel security enabled?

Merlin's comments about GCM are correct, but it has apparently created a misunderstanding as to what that actually means in practice.

The decision to use or NOT use a GCM cipher has no bearing on whether you should enable/disable tls-auth.

If you use a GCM cipher, and enable auth, the auth setting will be ignored for data channel packets (but NOT tls-auth and control channel packets). All that means is that the process of encryption and authentication (HMAC) of packets is more efficient, since authentication is part of the GCM cipher itself.

Given that ciphers are typically negotiated these days between client and server, you're probably going to end up w/ a GCM cipher anyway. That's just the way things are naturally evolving. But even if you didn't use GCM, it's NOT like the older CBC methodology is insecure or unsafe.

Frankly, I'm NOT convinced that using auth and/or tls-auth is all that advantageous to the average user. As I said before, it's just an *additional* layer of security. But it adds overhead and complexity to the config. Even if you end up the target of a DDOS attack, it's unlikely these options are going to provide all that much protection given the resource limits of your router. And given that OpenVPN has to run in user-space, it can always benefit from the elimination of unnecessary operations.

That's NOT to suggest I don't use these options myself from time to time. But I wouldn't hesitate to eliminate them either if I was looking to eke out as much efficiency as possible.

Note: Allegedly these options also provide some "stealthiness", if that matters to you. IOW, it helps to hide the fact the traffic is from a VPN. But I have my doubts as to its effectiveness, since I've seen plenty of users getting blocked w/ these options enabled.

Anyway, if you continue to use tls-auth, probably the bigger or more relevant question is whether you should perhaps use tls-crypt instead.

 

[maxbraketorque]

...

Anyway, if you continue to use tls-auth, probably the bigger or more relevant question is whether you should perhaps use tls-crypt instead.

These have been very interesting and helpful comments. I've only been using HMAC. No tls control channel security. Must admit that I'm not sure if that's sufficient for a simple site-to-site VPN link.