search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.03k stars 5.49k forks source link

Configurable SSL cipher suite #9691

Closed tgurr closed 2 years ago

tgurr commented 4 years ago

Description

'Vulnerable' cipher suites accepted by this service via the TLSv1.0 protocol:

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

'Vulnerable' cipher suites accepted by this service via the TLSv1.1 protocol:

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

'Vulnerable' cipher suites accepted by this service via the TLSv1.2 protocol:

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

https://github.com/go-gitea/gitea/pull/913 added configurable SSH cipher suite, it would be nice to have the same to configure the SSL cipher suite since currently TLSv1.0 and TLSv1.1 are still accepted which shouldn't be used in 2020 anymore: https://blog.qualys.com/ssllabs/2018/11/19/grade-change-for-tls-1-0-and-tls-1-1-protocols and it would also be nice to configure excludes for TLSv1.2 to get rid of the weak ones there as well / provide a way to configure them in general.

bagasme commented 4 years ago

@tgurr and perhaps enforcing TLS v1.2?

tgurr commented 4 years ago

@bagasme no objections from my side, maybe it should just be the default setting then. Just a note and directly related to Gitea, we encountered some problems on Windows 7 / Server 2008 when disabling TLSv1.0 and TLSv1.1 in other software, they're EOL anyways, but there may still be use cases for it.

clarfonthey commented 4 years ago

It may be worthwhile to simplify the configuration options to allow picking between some of Mozilla's recommendations (i.e. Modern, Intermediate, or Old), as shown here: https://wiki.mozilla.org/Security/Server_Side_TLS

Also, adding onto this: this is TLS, not SSL. It seems pedantic but it is important to mention.

CRCinAU commented 4 years ago

Oh good - I managed to find this when looking for the exact same... Currently, I see:

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   h2, http/1.1, acme-tls/1 (advertised)
 ALPN/HTTP2 h2, http/1.1 (offered)
...
 Has server cipher order?     no (NOT ok)
...
 Strict Transport Security    not offered
...
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    VULNERABLE, uses 64 bit block ciphers
...
BEAST (CVE-2011-3389)                     TLS1: ECDHE-ECDSA-AES256-SHA
                                                 ECDHE-ECDSA-AES128-SHA
                                                 ECDHE-RSA-AES256-SHA
                                                 AES256-SHA
                                                 ECDHE-RSA-AES128-SHA
                                                 AES128-SHA
                                                 ECDHE-RSA-DES-CBC3-SHA
                                                 DES-CBC3-SHA 
                                           VULNERABLE -- but also supports higher protocols  TLSv1.1 TLSv1.2 (likely mitigated)
 LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches

It would certainly be good to get this part of things configurable...

zeripath commented 4 years ago

The place to adjust this would likely be in modules/graceful/server.go:97:ListenAndServeTLS

you'd need to add the appropriate settings to modules/settings/setting.go probably add some settings at line 91 and line 580.

rmbleeker commented 3 years ago

Is this actively being worked on? I got back a network scan showing the same results and was asked if I could disable the potentially vulnerable cipher suites. If this is not on the roadmap for a near future Gitea release I might just install a reverse proxy as a work-around.

eduardok commented 3 years ago

Is this actively being worked on? I got back a network scan showing the same results and was asked if I could disable the potentially vulnerable cipher suites. If this is not on the roadmap for a near future Gitea release I might just install a reverse proxy as a work-around.

Edited my comment, you are right, I used the ones for SSH (all good), but it seems HTTPS is still not covered, I see I have a reverse proxy set up to get that cleared.

CRCinAU commented 3 years ago

Running 1.15.x, I see a much more sane config without having to alter the app.ini anywhere:

SSLv2
 - 
SSLv3
 - 
TLSv1
 - 
TLSv1.1
 - 
TLSv1.2 (server order)
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 256   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384            
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 256   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256            
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 256   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256      
TLSv1.3 (no server order, thus listed by strength)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                             
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                       
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256

Looks like at some point it was tightened up a bit...

zeripath commented 3 years ago

Describe the settings, the values it would take and what you expect them to do and it would be relatively easy to implement.

eduardok commented 3 years ago

M_SHA256

I will see if I have time to upgrade my Gitea to latest this Monday/tomorrow, then will make it visible to the scanner and see if it still complains, otherwise I'll let you know what ciphers should be removed.

rmbleeker commented 3 years ago

Running 1.15.x, I see a much more sane config without having to alter the app.ini anywhere:

SSLv2
 - 
SSLv3
 - 
TLSv1
 - 
TLSv1.1
 - 
TLSv1.2 (server order)
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 256   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384            
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 256   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256            
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 256   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256      
TLSv1.3 (no server order, thus listed by strength)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                             
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                       
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256

Looks like at some point it was tightened up a bit...

It's curious that I don't see any 3DES ciphers show up in your overview, while our network scan reports that they are offered by Gitea 1.15.3. Here is the relevant part of the scan report: https://gist.github.com/rmbleeker/13168441a2297e0f10faa39242c072a4

rmbleeker commented 3 years ago

Describe the settings, the values it would take and what you expect them to do and it would be relatively easy to implement.

It would probably be a good idea to implement this in the way Nginx does it for example: http://nginx.org/en/docs/http/ngx_http_ssl_module.html So the options would then be:

edit: since Gitea works with comma separated lists rather than space separated, modified my comment slightly for consistency with other Gitea options that take a list of values.

CRCinAU commented 3 years ago

they are offered by Gitea 1.5.3

Note that I'm running 1.15.x not 1.5.x... Earlier versions did indeed offer everything and the kitchen sink...

rmbleeker commented 3 years ago

they are offered by Gitea 1.5.3

Note that I'm running 1.15.x not 1.5.x... Earlier versions did indeed offer everything and the kitchen sink...

Oops, typo. We're also running 1.15.3. I corrected my earlier post.

eduardok commented 3 years ago

I've upgraded to 1.15.4 and made it listen on all interfaces again. My Tenable scanner runs late on Wednesday, so I'll post results on Thursday.

eduardok commented 3 years ago

Ok, Tenable shows these two as issues:

  Medium Strength Ciphers (> 64-bit and < 112-bit key, or 3DES)

    Name                          Code             KEX           Auth     Encryption             MAC
    ----------------------        ----------       ---           ----     ---------------------  ---
    ECDHE-RSA-DES-CBC3-SHA        0xC0, 0x12       ECDH          RSA      3DES-CBC(168)          SHA1
    DES-CBC3-SHA                  0x00, 0x0A       RSA           RSA      3DES-CBC(168)          SHA1
zeripath commented 3 years ago

Describe the settings, the values it would take and what you expect them to do and it would be relatively easy to implement.

CRCinAU commented 3 years ago

I don't see the SSL ciphers you see in your scan. I'm wondering if it has more to do with the systems openssl version?

rmbleeker commented 3 years ago

Describe the settings, the values it would take and what you expect them to do and it would be relatively easy to implement.

I haven't been able to find any guidelines for a naming convention for the options in the app.ini file, but here's a suggestion for the protocols and ciphers:

Here's my suggestion for options to configure the HSTS header:

rmbleeker commented 3 years ago

I don't see the SSL ciphers you see in your scan. I'm wondering if it has more to do with the systems openssl version?

That might be the case if Gitea (or Go) is using the system's OpenSSL for TLS connections. I have Gitea on a RHEL7 system which has OpenSSL 1.0.2k-fips as it's OpenSSL library and seeing the same cipher suites in our scans as @eduardok.

CRCinAU commented 3 years ago

I'm using OpenSSL 1.1.1l - so I'm guessing that explains the cipher selections.

Technically, OpenSSL 1.0.2 is no longer in support.

rmbleeker commented 3 years ago

Technically, OpenSSL 1.0.2 is no longer in support.

The developers of OpenSSL might not support it any longer, but as long as RHEL7 is supported, Red Hat supports any of the software that's found in their official repositories. Either way, once we're able to configure the list of ciphers Gitea is allowed to use for TLS connections I'll disable all ciphers using 3DES.

CRCinAU commented 3 years ago

You shouldn't need to. Modify the system policy: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

(EDIT: Yes, I know this is for RHEL8, but the procedures are pretty much the same)

eduardok commented 3 years ago

You shouldn't need to. Modify the system policy: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

(EDIT: Yes, I know this is for RHEL8, but the procedures are pretty much the same)

Very good point, I've changed it to FUTURE now, and I should know after tomorrow's scan.

rmbleeker commented 3 years ago

You shouldn't need to. Modify the system policy: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening (EDIT: Yes, I know this is for RHEL8, but the procedures are pretty much the same)

Very good point, I've changed it to FUTURE now, and I should know after tomorrow's scan.

I assume you're on RHEL8 then? Because if these commands to conveniently change the crypto policy system-wide exist on RHEL7, I haven't been able to find them for years. All the documentation I have for RHEL7 suggests that this needs to be configured on a per-application basis, which is why I'm interested in this functionality for Gitea. I would love to be proven wrong though.

eduardok commented 3 years ago

You shouldn't need to. Modify the system policy: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening (EDIT: Yes, I know this is for RHEL8, but the procedures are pretty much the same)

Very good point, I've changed it to FUTURE now, and I should know after tomorrow's scan.

I assume you're on RHEL8 then? Because if these commands to conveniently change the crypto policy system-wide exist on RHEL7, I haven't been able to find them for years. All the documentation I have for RHEL7 suggests that this needs to be configured on a per-application basis, which is why I'm interested in this functionality for Gitea. I would love to be proven wrong though.

Gitea is running alone on a Fedora 33, and update-crypto-policies is available. It won't be running there for much longer, but it would be nice to clear this doubt before I move it.

lunny commented 3 years ago

Gitea (or Go) itself doesn't depend on openssl. If you want that, you could use nginx as a reverse proxy of Gitea. I mean for a workround before there is any PR to send and merged.

eduardok commented 3 years ago

You shouldn't need to. Modify the system policy: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

(EDIT: Yes, I know this is for RHEL8, but the procedures are pretty much the same)

As indicated by @lunny , update-crypto-policies had no effect, the scan still shows the same weak ciphers.

CRCinAU commented 3 years ago

I wonder why my scan is so different to yours then.... Same gitea version - just I'm using Fedora 34 instead of RHEL7...

As a reminder, I get:

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
 - 
SSLv3
 - 
TLSv1
 - 
TLSv1.1
 - 
TLSv1.2 (server order)
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 256   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384            
 xc02b   ECDHE-ECDSA-AES128-GCM-SHA256     ECDH 256   AESGCM      128      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256            
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 256   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256      
TLSv1.3 (no server order, thus listed by strength)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                             
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                       
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256
zeripath commented 3 years ago

I think I have an answer as to why

I suspect @CRCinAU is using letsencrypt and the @eduardok is not.

CRCinAU commented 3 years ago

Likely, I do use letsencrypt...

andypost commented 3 years ago

having issue to build 1.15.4 for Alpinelinux because of RSA keys in tests. Basically we found no way to point tests to use pre-configured /.gitconfig and ~/.ssh even trying to override HOME for tests

Ref https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26273

zeripath commented 3 years ago

having issue to build 1.15.4 for Alpinelinux because of RSA keys in tests. Basically we found no way to point tests to use pre-configured /.gitconfig and ~/.ssh even trying to override HOME for tests

Ref https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26273

This doesn't seem completely related to this issue and is more related to #17175.

I don't understand though as #17376 should have fixed this. So I'm confused as to why this is still happening.

It would be helpful to see the contents of /etc/ssh/ssh_config

You could patch integrations/git_helper_for_declarative_test.go:withKeyFile() to add another -o option to specifically allow an rsa cipher algorithms.

andypost commented 3 years ago

@zeripath thank you, following

zeripath commented 3 years ago

Aha! #17376 only fixed the host key algorithm not the pub key algorithm part of the problem.

So you don't need to add ssh-rsa to your host keys but you would need to add it to the publickeys (!)

Damn. Need to do a bit more work here.

for others wanting to replicate the bug but who have an ssh that has ssh-rsa in by default

ssh git@localhost -p 2222 -o HostKeyAlgorithms=-ssh-rsa -o pubkeyacceptedkeytypes=-ssh-rsa -i ~/.ssh/id_rsa

would disable the ssh-rsa algorithm. (Note that the HostKeyAlgorithms=-ssh-rsa alone works fine)

zeripath commented 3 years ago

OK looking at how openssh responds and the gossh server responds - it looks like the gossh server is missing a SSH2_MSG_EXT_INFO response. This looks a lot like we're either going to have to rip out the x/crypto/ssh stuff or get patches in upstream. :cry: (This is being proposed at https://github.com/golang/go/issues/49269)

rmbleeker commented 3 years ago

OK looking at how openssh responds and the gossh server responds - it looks like the gossh server is missing a SSH2_MSG_EXT_INFO response. This looks a lot like we're either going to have to rip out the x/crypto/ssh stuff or get patches in upstream. cry (This is being proposed at golang/go#49269)

I assume this response was meant for #17175 since that issue deals with SSH, whereas this issue deals with SSL/TLS?

zeripath commented 3 years ago

@rmbleeker yeah unforunately we have a cross-issue conversation going on. I'll open another issue for @andypost's reported issue.

If you're interested in configurable SSL options please look at my PR #17440