Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Consider limiting the TLS ciphers we use by default #3682

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.

Sign up for GitHub

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

Jump to bottom
Open
1 of 4 tasks
carlosmn opened this issue Mar 14, 2016 · 2 comments
Open
1 of 4 tasks

Consider limiting the TLS ciphers we use by default #3682

carlosmn opened this issue Mar 14, 2016 · 2 comments

Comments

@carlosmn
Copy link
Member

OpenSSL is not particularly proactive in changing the defaults, and it's probably too much to expect each user of the library to worry about this when it generally starts from a PoC which gains features.

So let's set our own list of safe ciphers to use. Because TLS is terrible in general, we should also provide an escape hatch and provide a git_libgit2_opts() way of the user letting us know not to do it.

Unless someone comes up with a better list, we'll probably go with https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L22 but exclude RC4 (because lol).

  • Do this for OpenSSL
  • Do this for SecureTransport
  • Do this for WinHTTP
  • Do this for libcurl (when connecting to HTTPS proxies)
@dbussink dbussink mentioned this issue Mar 14, 2016
Merged
ethomson pushed a commit to ethomson/libgit2 that referenced this issue Apr 11, 2016
@dbussink
Setup better defaults for OpenSSL ciphers
c1ec732 
This ensures that when using OpenSSL a safe default set of ciphers
is selected. This is done so that the client communicates securely
and we don't accidentally enable unsafe ciphers like RC4, or even
worse some old export ciphers.

Implements the first part of libgit2#3682
@tiennou
Copy link
Contributor

tiennou commented Feb 7, 2018

I'd like to discuss this, because I wanted to tackle #4418 failing because our cipherlists are inconsistent between backends.

Right now, only OpenSSL handles our GIT_OPT_SET_SSL_CIPHERS option. The mbedTLS backend inherited its own separate (handtuned by yours truly) copy of it because the names didn't match, and I'm looking at SecureTransport, which uses enums.

It means the OpenSSL names are somewhat, well, "not-that-standard". RFC5246 defines a list, and that's what mbedTLS, SecureTransport (and GNUTLS, just for kicks) use, apart that the latter has no easy string-mapping API. It seems the libcurl ones depends on what backend it uses, and WinHTTP does its thing too, so 😭.

Anyway, I think a shared master list of default ciphers is preferable, so would it be a problem if I broke the API/OpenSSL users by switching names ? At least we could have a "consistent API" in that regard…

I don't think there's any way around that but to have a "table of ciphers + names" somewhere though, so I want to know if I'm overthinking it 😉.

@pks-t
Copy link
Member

pks-t commented Feb 8, 2018

I agree the current API has some problems, especially considering that there is not even documentation regarding the cipher list's format. And it definitly is unfortunate that the user has to be aware of what SSL backend is in use. So I'm definitly in favor of having a mapping table for matching "our" name with "their" name, with "their" being the respective backend that is currently in use.

@tiennou tiennou mentioned this issue Aug 27, 2018
Open
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tiennou @carlosmn @pks-t