add support for disabling TLSv1.0

[skrobul]

Many organizations run their applications using in environments that fall into scope of PCI-DSS compliance audits. One of the requirements set out by standard is to migrate to more secure protocols if possible.

PCI Security Standards council has advised to migrate away from TLSv1.0 over last few years and recently set a migration deadline of 30 June 2018 (see this article for more details).

Change proposed in this commit gives an user option to disable TLSv1.0 during bind, while still leaving the TLSv1.1 and TLSv1.2 enabled. SSLv2 and SSLv3 are permanently disabled (as they should).

Default behaviour is not changed if the no_tls option is not defined.

Related: #980

[evanphx]

This looks fine. I merged a similar PR that caused this to need to be rebased. Can you do that and then I'll merge it.

[themikejr]

Gentle bump :-) My team would benefit from this.

[skrobul]

Sorry I forgot to comment, this has been rebased in e142b9f and it should be ready to merge

[MikaelSmith]

I'd love to see this fixed, although a more forward-ready implementation would be nice: the ability to list what TLS versions to allow would support disabling TLSv1.1 in the future.

[HoneyryderChuck]

Why does puma have their own "minissl", instead of using ruby's "openssl" library?

[skrobul]

Tiago, Ha! I was thinking the same, but after looking into code, the minissl is just a class name that is used to wrap SSL related functionality. Upon compilation it still uses OpenSSL. See more details in #1561

…

On Tue, 28 Aug 2018, 19:14 Tiago, ***@***.***> wrote: Why does puma have their own "minissl", instead of using ruby's "openssl" library? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1562 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALOqJ_57NOYJofy0-zASSw9USBjHwCCks5uVXqNgaJpZM4TYVuw> .

[HoneyryderChuck]

@skrobul I get that, minissl is just an OpenSSL binding. However, the ruby std library already provides one, and with a stable albeit clunky API, which allows you to do the things this PR aims at in a future-proof way. So my question was really: why does puma feel the need to support their own openssl binding which has no API parity with ruby-openssl and has no clear advantage besides arguably "leaner" (and therefore more limited, hence this PR)? There must be a reason, right?

[MSP-Greg]

with a stable albeit clunky API

Given that:

1. Ruby OpenSSL has deprecated ssl_version and replaced it with two attributes
2. RubyGems is now only supporting TLSv1.2 connections
3. OpenSSL 1.1.1 with TLSv1.3 has been released (2018-09-11)

Rather than add an no_tlsv1 option, might it be better to add a min_vers(ion) option? People may want a no_tlsv1_1 option in a year or so...

EDIT: just checked here (GitHub.com), and it is also only using TLSv1.2

[mmizani]

gentle bump, would be great to have this feature.

[hshyk]

Has there been any updates with this? This would be great if we could disable TLSv1. Also, would be nice for configuration to disable TLSv1.1.

[schneems]

Not clear based off of the diff, is it possible to trigger this without explicitly supplying a bind in the dsl?

If not could we add this as a new dsl option?