Change Details

Blowfish is vulnerable to Sweet32 attacks and should not be used for any new deployments, regardless of key length (it's the //block// size that makes it vulnerable). We still support it in 1.3 but we have to revert its removal from OpenVPN to do that, and it will likely become impractical as OpenVPN keeps moving forward. We should remove support for it from 1.4/Sagitta. The good thing is that the default — no `encryption` option specified — allows clients to use any cipher supported by OpenVPN. Thus for setups that have no `encryption` option, nothing will change, except very old clients will be unable to connect — but people need to update those very old clients anyway. For systems where `encryption` is explicitly set to `bf128` or `bf256`, removing that option from their config will be a //security upgrade// since it will allow clients to negotiate a more secure cipher. Since there is a possibility that someone uses old clients with cipher set to Blowfish, this is a breaking, not really migratable change, and it should be properly communicated as such.

Blowfish is vulnerable to Sweet32 attacks and should not be used for any new deployments, regardless of key length (it's the //block// size that makes it vulnerable). And DES, well, there's nothing to say — DES has been insecure for ages by now. We still support it in 1.3 but we have to revert its removal from OpenVPN to do that, and it will likely become impractical as OpenVPN keeps moving forward. We should remove support for those insecure ciphers from 1.4/Sagitta. The good thing is that the default — no `encryption` option specified — allows clients to use any cipher supported by OpenVPN. Thus for setups that have no `encryption` option, nothing will change, except very old clients will be unable to connect — but people need to update those very old clients anyway. For systems where `encryption` is explicitly set to `des`, `bf128` or `bf256`, removing that option from their config will be a //security upgrade// since it will allow clients to negotiate a more secure cipher. Since there is a possibility that someone uses old clients with cipher set to Blowfish or DES, this is a breaking, not really migratable change, and it should be properly communicated as such.

Blowfish is vulnerable to Sweet32 attacks and should not be used for any new deployments, regardless of key length (it's the //block// size that makes it vulnerable). And DES, well, there's nothing to say — DES has been insecure for ages by now. We still support it in 1.3 but we have to revert its removal from OpenVPN to do that, and it will likely become impractical as OpenVPN keeps moving forward. We should remove support for itthose insecure ciphers from 1.4/Sagitta. The good thing is that the default — no `encryption` option specified — allows clients to use any cipher supported by OpenVPN. Thus for setups that have no `encryption` option, nothing will change, except very old clients will be unable to connect — but people need to update those very old clients anyway. For systems where `encryption` is explicitly set to `des`, For systems where `encryption` is explicitly set to `bf128` or `bf256`, removing that option from their config will be a //security upgrade// since it will allow clients to negotiate a more secure cipher. Since there is a possibility that someone uses old clients with cipher set to Blowfish or DES, this is a breaking, not really migratable change, and it should be properly communicated as such.