Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop TLSv1 and TLSv1.1 support from intermediate policy #210

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
2 participants
@emansom
Copy link
Contributor

commented Nov 30, 2018

TLS 1.0 is known to be vulnerable and has been declared end of life. TLS 1.2 support is wide-enough that it shouldn't cause any breakage.

Drop TLSv1 and TLSv1.1 support from intermediate policy
TLS 1.0 is known to be vulnerable and has been declared end of life. TLS 1.2 support is wide-enough that it shouldn't cause any breakage.
@LeoColomb

This comment has been minimized.

Copy link
Member

commented Nov 30, 2018

In the intermediate profile, I think it's better to stick to the Mozilla recommandation, even if a bit outdated. There is the modern profile for "modern" configuration.

@emansom

This comment has been minimized.

Copy link
Contributor Author

commented Nov 30, 2018

It would drop support for Internet Explorer <9, Java <7, Android <4.4.4 and Windows XP.

Dropping Java <7 and Android 4.4 support may pose issues, the other contenders shouldn't be targeted from the intermediate preset; they belong to the old preset.

All other browsers and operating systems support TLS 1.2. See https://caniuse.com/#feat=tls1-2 and https://support.globalsign.com/customer/portal/articles/2934392-tls-protocol-compatibility

@LeoColomb

This comment has been minimized.

Copy link
Member

commented Nov 30, 2018

Dropping Java <7 and Android 4.4 support may pose issues

Well, to be honest, I prefer keeping these values for a large compatibility as a goal for the intermediate profile. We can definitely highlight modern profile, but we should keep the intermediate one as a OK-ish compatible fallback.

@emansom

This comment has been minimized.

Copy link
Contributor Author

commented Nov 30, 2018

@LeoColomb

This comment has been minimized.

Copy link
Member

commented Dec 8, 2018

TLS 1 is not an OK-ish fallback.

OK, agreed, then could you just remove TLSv1? Thanks!

@emansom

This comment has been minimized.

Copy link
Contributor Author

commented Dec 8, 2018

TLS 1 is not an OK-ish fallback.

OK, agreed, then could you just remove TLSv1? Thanks!

According to research from SSLLabs [1] and Mozilla [2]: 99% of clients that support TLS 1.1, also support TLS 1.2 and prefer connecting with TLS 1.2.

[1]: https://community.qualys.com/thread/16565-is-there-a-reason-for-still-having-tlsv11-enabled
[2]: https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/

@LeoColomb

This comment has been minimized.

Copy link
Member

commented Dec 19, 2018

For instance, Chrome (Chromium) just started to deprecate TLSv1.0/1.1.
Removal is planned for 2020.
https://www.chromestatus.com/feature/5654791610957824

An alternative to remove these version here would rename policy files:

  • policy_deprecated
  • policy_current or policy_mainstream
  • policy_future

LeoColomb added a commit that referenced this pull request Feb 1, 2019

LeoColomb added a commit that referenced this pull request Feb 1, 2019

LeoColomb added a commit that referenced this pull request Feb 1, 2019

@LeoColomb

This comment has been minimized.

Copy link
Member

commented Feb 1, 2019

I've just rotated policies as I suggested above.
Thanks again, @emansom!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.