search

openssl / project

Tracking of project related issues
2 stars 1 forks source link

Create proposal for deprecation of TLS 1.0/1.1 and DTLS 1.0 protocols #750

Closed t8m closed 1 month ago

t8m commented 4 months ago

The proposal should include documentation changes and how the libssl will behave in no-deprecated build according to the TLS version support.

BugOfBugs commented 4 months ago

no-deprecated has nothing to do with protocols. Excludes only API. Too narrow task. We did not discuss it. Discussed default to disable deprecated. Ban, rather than exclude from build.

Add the protocols to list disabled, or deprecated_disablables in Configure. Nothing extra. Warn user that you exclude the protocols. Suggest how to include.

Default option for compiler affects most users, especially who do not compile on their own. You may either defer this for several years, or warn user, and suggest to compile with enable-tls1_1. Most would be unable to recompile.

Exclusion from build does justify reports of error, like "not supported". No need to change them.

Problem with default limit, like MinProtocol: misleading report of error. - Not specific to TLS 1, or deprecation. You may leave it till later.

If you do not introduce default limit, your are done.

t8m commented 4 months ago

There is nowhere said that we cannot change the definition of no-deprecated in INSTALL.md to something like:

### no-deprecated

Don't build with support for deprecated features and APIs up until and including the version
given with `--api` (or the current version, if `--api` wasn't specified).
mattcaswell commented 4 months ago

In my mind deprecation is a very different thing to excluding a feature from the build. We have lots of deprecated things which are still available in the build.

To me deprecation is simply a clear communication to the user that a feature is obsolete or not recommended - with a view that such deprecated features may eventually be removed. It is premature to completely remove TLSv1.0/1.1 from the build at this stage.

These protocols are already partially deprecated in the sense that you have take explicit steps to turn them on (they are not included in the default security level). But we could do better to signal to the user that they should not use them. I see no problem with setting a default MinProtocol at TLSv1.2.

nhorman commented 3 months ago

Deprecation Proposal

Background

The TLS 1.0/1.1 and DTLS 1.0 protocols are old and generally speaking should not be used for new deployments. There is a desire to default disallow the use of these protocol versions, but still allow their usage for older deployments as said deployments upgrade to newer versions of OpenSSL, when their presence is required. As such we want to run time deprecate the above protocols, but allow opt-in usage as required on specific sites

Requirements

1) Deprecation/default disable-ment of protocol versions at run time 2) Re-enablement allowed via administrative intervention 3) Should prevent configured use by default, and provide warning when used at run time

Proposal

Given that minimum protocol versions can already be specified in the configuration file I would propose that deprecation be handled by explicitly setting the min_proto_version to TLS1_2_VERSION in SSL_CTX_new() . While this is not "deprecation" in the build time sense that we nominally use it in openssl, it is functionally appropriate here, in that this creates a default inability to use < TLS_1_2_VERSION, but allows for administrative override by adding an ssl_conf section which specifies that lower versions can still be used. Programatically this also be done with a call to SSL_CTX_set_min_version.

BugOfBugs commented 3 months ago

@t8m nowhere said that we cannot change definition

This is crazy, and corrupt. You move goal posts during match. You again propose, what we did not discuss. Definitions are all we have. One moment we discuss one definition. Next you redefine. You propose to introduce 2nd place, where to list removal. There should only be 1. You should apologize for mistake. Instead, you perpetuate it with yet more cheating. - Just in order to appear good.

@mattcaswell deprecation is a very different thing to excluding

You are right. It must remain. It is user, who is to choose to remove. Not maker. You may only warn that you intend to remove. But OpenSSL does not provide warning. I suggested such new feature. Simplest way: document.

doc/internal/man7/deprecation.pod vaguely suggests that compiler could warn, when you use deprecated. But does not, because #define OPENSSL_SUPPRESS_DEPRECATED. Anyway, the warning is only during compilation, rather than run.

premature remove TLSv1.0/1.1

Then @nhorman set milestone 3.5.0 by mistake. What it should be?

security level

Bug. Implicit. Should abolish. Or at least default to 0.

no problem with setting a default MinProtocol

Misleading reports of error are problem.

@nhorman protocol versions can already be specified in the configuration file propose that deprecation explicitly setting the min_proto_version to TLS1_2_VERSION in SSL_CTX_new()

2 statements not related. Configuration is not the same as SSL_CTX_new(). openssl.cnf is explicit. But you do not propose to change it. SSL_CTX_new() is implicit. Not explicit. I argued against implicit. You ignored.

t8m commented 3 months ago

OTC: We do not want to change the MinProtocol default setting. We will seek community input on making tls-1.0/1.1 dtls-1.0 compiled off by default in 4.0 version. We will post the question to oss-security ML.

@nhorman to post that question to the oss-security ML.

nhorman commented 3 months ago

email sent

t8m commented 2 months ago

We've got conflicting feedback. @nhorman to summarize the existing feedback and create a GH discussion and a blog post (also announce it on openssl-users and GH Discussions Announcements).

nhorman commented 2 months ago

Feedback summary: https://www.openwall.com/lists/oss-security/2024/08/06/1

It seems that we have a fairly split decision:

About 1/2 the responders are supportive of immediate deprecation and removal in the near future, as they have already migrated to TLS1.2 or later

The other half represent platforms that are old or otherwise un-upgradable (medical and military devices noted expressly here) that cannot move from TLS 1.1/1.0, would immediately enable any such deprecation, and would not be able to use openssl if the code were removed.

The remainder of the conversation revolved around workarounds for such devices, and how this disablement should be presented to users (build time warnings, run time log messages, etc).

Thought on a proposal: Based on the conversation, I think that a deprecation with a build time re-enablement is generally acceptable, even if a significant percentage of our users will just enable it again immediately.

As for complete removal, I would think that the next major (4.0) release is likely an ok target. That will allow us at least one more LTS release in the 3.x series which users can lean on for the next 5 years. At that point in time, the long tail of "can't upgrade" use cases should diminish to the point that they are likely to be near the end of their supported product lifetime, or can continue on via extended support contract arrangements.

Next Actions: Write up this summary in a blog post with the proposed action above, open a discussion to pull in additional community input, and plan for the action in our upcoming releases.

BugOfBugs commented 2 months ago

@t8m create a GH discussion

It is already: https://github.com/openssl/openssl/issues/15335 You ignore it. Created new one here. I reminded of the discussion. Now you try to create yet new one in order to forget these 2.

blog post

Yet 3rd discussion?..

You should invite people to 1 discussion, rather than isolate them in multitude of discussions.

@nhorman Feedback

You did not get much. Many of 30 replies are off topic, or speculation about things that do not use themselves.

You created 4th, separate discussion. In your announcement there you failed to link to discussion here, and: https://github.com/openssl/openssl/issues/15335

devices

Complainants forgot that they do not use OpenSSL to access them. They enable old TLS1 in browser. Browsers have their own SSL. They keep it. Do not intend to deprecate.

You forgot to mention a complaint that some distributors no longer update old systems. For them solution is trivial: deprecation would not affect them anyway. Unless other end of communication deprecates. But that is for the other end to decide.

removal

To deprecate means to disable. Not to remove. You should keep code of old TLS, and SSL forever. Even if you no longer update code for quality, or security. Just warn that update is neccessary, but no more. OpenSSL3 already removed SSL2. Can not enable. Do not remove SSL3, TLS1. May remove, if no longer works with new code; could update old code, but too lazy, because deprecated anyway.

You may deprecate, if you cease update, while update is due. Or to save memory. How much memory old code takes?

You could deprecate immediately, and suggest distributors compile 2 options: disabled, and enabled. If memory to save is too little, no need to deprecate.

I doubt update is due. So, old protocols may remain forever, even if no one uses. Someone may use any time.

Yet, I presume, everybody wants to save memory. Then you may decide by:

Problem for all users, except the latter: may encounter old TLS1 on other end any time, even after century. Most would prefer not to miss it. That is on unlimited network, like Internet. Only limited networks may guarantee absence of old.

Warning during run may annoy, and clog log. Best write once in documentation, and openssl.cnf. Prefer documentation in README. There the warning is easy to notice. Among various pages of man - not easy. Add also warning about deprecated SSL3. Do so immediately. Would serve as trial for warning about TLS1 in future.

List deprecation in:

t8m commented 2 months ago

This is waiting on the blog approval.

nhorman commented 1 month ago

blog post approved and posted, discussion open here: https://github.com/openssl/openssl/discussions/25427

nhorman commented 1 month ago

Discussion open and in flight. Will collect and present results via https://github.com/openssl/private/issues/638

levitte commented 3 days ago

There is nowhere said that we cannot change the definition of no-deprecated in INSTALL.md to something like:

### no-deprecated

Don't build with support for deprecated features and APIs up until and including the version
given with `--api` (or the current version, if `--api` wasn't specified).

I don't see a need to redefine this, if you understand "API" as not just being about function signatures, but also about (documented) behaviour. If we deprecate certain TLS versions, I would absolutely expect that with an OpenSSL build with no-deprecated configured, functions that deal with TLS versions will return an error for the deprecated TLS versions. Because of this, it was perfectly valid to bring up no-deprecated here.

levitte commented 3 days ago

Argh, didn't notice the discussion link. I'll have to repeat myself...

BugOfBugs commented 1 day ago

error deprecated

Fails to compile, if you refer to old function. Only new functions compile. Old program fails to run, because fails to find deprecated.

functions deal with TLS versions

None. https://github.com/openssl/project/issues/750#issuecomment-2219113004 no-deprecated has nothing to do with protocols. Excludes only API.

@t8m arbitrarily redefined. But does not know what he proposes. Even if API dealt with protocols, you do not know which. There is no list.

valid bring no-deprecated here

What do you mean?

didn't notice discussion

No worry. Fell free to create 6th Discussion. They do always https://github.com/openssl/project/issues/750#issuecomment-2287528943. You must unify discussions that they split. Make 1. Only when complete, may change code. Remove from settings Project, and any other possibility to split Discussion.