Consider warning or removing options in DPC that lower security

[ld0614]

It has been pointed out on discord that DPC currently has a couple of options that lower the security of the solution overall. A couple that have been pointed out are:

1. Ability to disable NPS server validation checks
2. Ability to configure a tunnel without custom cryptography being enabled (Default encryption is tripledes I believe?)
3. Ability to configure custom cryptography with insecure options

As DPC does not collect any kind of telemetry it is not possible to understand how many customers may be impacted by removing these features. Current feedback is that some (very large) customers disable the NPS checks so that they don't have to manage the NPS server lists individually. I also don't see an option to enforce custom cryptography as this requires configuration on the server side and unless they were set up correctly, a lot of people would struggle to upgrade to this configuration.

Removing insecure custom cryptography is easier as it can be done at the ADMX level rather than removing the functionality entirely, this should allow existing people to continue to use this setting or people can make use of manual registry updates if they really want it.

I'll also add warnings into the profile generation process to highlight that these options are insecure and ideally links to places where they can understand the issues and how to remediate @richardhicks I sense a blog post or 2 coming 😉. Unfortunately not everyone knows that the event logs exist and so only notice when the profile breaks. As such any breaking change will need a major revision (6.x) and will have to be telegraphed in advance

Please do input into these discussions. Overall DPC attempts to be flexible but opinionated, always trying to push people towards a more secure configuration and attempting to minimise the about of knowledge the average AOVPN administrator needs to have to setup a secure and functioning system.

[ryannewington]

IMO I don't think DPC should try to prevent configuration that AOVPN supports and is happy with.

Guiding users down a happy path and safe defaults is fine.

Blocking choices that are valid, is just frustrating for users who need them.

Eg I've got a VPN appliance that doesn't support all the latest crypto. But I've done my risk assessments and deemed it suitable for our use cases for now.

DPC takes something objectively horrible and difficult to configure and makes it what it should have been from day 1. There's so much value it adds doing that. But I don't think we add value by making opinionated security decisions on behalf of admins capable of doing their own risk assessments.

It would never make me replace a VPN appliance, it would just make me not use DPC.

Just my 2c

[richardhicks]

You make a good point. Some non-Microsoft solutions support client-based VPN but don't adhere to all accepted standard security best practices. If someone wants to implement Always On VPN in a sub-optimal configuration, DPC shouldn't encourage it, but it should allow it if an administrator decides to choose this option.

@ld0614 What are your thoughts?

[ld0614]

It is something that I'm incredibly conflicted about simply because of the range of technical skills the DPC users have from the super expert all the way through to 'My Boss wants this so I guess I do VPNs now'. I suppose I can rationalise and make my approach consistent with the following approach:

• Not implement 'features' that are less secure than the currently implemented approach where they create significant additional work and actively create UX and validation issues such as with CHAP authentication
• Provide warnings in both the help text and Event logs for known low security functionality such as MD5 integrity. This should hopefully educate new joiners to AOVPN
• Potentially implement a 'Shut-up I Know' advanced option to disable these client side warnings for administrators that either accept the risks or don't care - at that point we've done everything we can as a community project to advise against it
• Continue to allow low(er) security functionality where it is already implemented, is part of a Enumerated value/list (such as integrity checks), meets a specific business customers need with limited overall product impact or a compelling case is made by the community

[ryannewington]

Yeah it's a tough one. It depends on your project goals tbh.

I've got a few open source products-turned-commercial and have learnt a few lessons here. If commercialization is the goal, I'd suggest being a bit more open about what you support.

It comes down to that fact that no one is going to choose your product because it doesnt support something, but they will choose not to use it if it doesn't support what they need in their environment.

Choosing not to support something because it is difficult or complex is totally valid. Choosing not to support it because people shouldn't be using it... You may just be cutting off revenue sources for yourselves.

My personal strategy was to make sure my product was open to as many organizations as possible, warning them appropriately about low-security decisions they may make, providing guidance around them, but importantly, making sure my product didnt create new security problems they wouldnt have had if they werent using my product.

Again, just a perspective and personal 2c :)

[ablanken]

1. Ability to disable NPS server validation checks

This one is useful for those running third party RADIUS servers. The risk introduced can be mitigated in other ways