Disable the old versions of TLS on buchgr / bazel-remote

[tushar150]

We are using buchgr/bazel-remote container on our Linux environment. Recently Tlsv1 and Tlsv1.1 is detected on the container and we are not sure how to get rid of these vulnerabilities on this container. Any suggestion/recommendation would be helpful.

[mostynb]

Hi, I wonder if you could test a build of #709 to see if it disables TLS 1.0 and 1.1?

[tushar150]

Thanks for quick updates, We have updated the image with new build and awaiting for new scan results. I will keep you posted.

[tushar150]

Still old TLS version is detected. May you suggest

[tushar150]

I am not able to build image . Is it possible for you to build image and share the link.

[mostynb]

I tried to push a test image for you here, could you try that? index.docker.io/mostynb/bazel-remote-cache@sha256:b9ee62c7826afe550b3dd86b96c234a6359a8932443dfc6afb11f0a471b0773d

[tushar150]

Thanks for quick updates on this.

old tls version 1 and tls1.1 are gone.

There are some weak ciphers exists (Birthday attacks against TLS ciphers with 64bit block size vulnerability (Sweet32)), is it possible to block these as well.
ECDHE-RSA-DES-CBC3-SHA
DES-CBC3-SHA

[mostynb]

I looked into this a bit. While it is possible to specify a custom set of ciphers by setting CipherSuites in the tls.Config, there isn't a good way to get the current version of go's default ciphers. If we were to hardcode a list, then we would need to manually check that it was up to date. So I'm not sure this would be a wise decision long term.

There is a bit of a hack that has been suggested: write a function that uses net.Pipe to do a TLS handshake with itself, and set the GetCertificate field of the tls.Config to a function that reports the supported cipher suites, and use those values in the tls.Config that we start the http/grpc servers with. But I would need to think this through a bit before deciding if it's worthwhile.

Do you know of any clients that are actually using these old cipher suites to communicate with bazel-remote? If not, then maybe it's OK to live with these old cipher suites being supported but not used?

[tushar150]

Would it be possible to expose ciphers as configuration? May you suggest more information on using tls.Config and how to use it? We don't know any clients that are actually using these old cipher suites to communicate with bazel-remote but security team see this as an issue so we need to block it in one way or other at our end.

…

On Fri, 27 Oct 2023 at 01:21, Mostyn Bramley-Moore ***@***.***> wrote: I looked into this a bit. While it is possible to specify a custom set of cophers by setting CipherSuites in the tls.Config, there isn't a good way to get the current version of go's default ciphers. If we were to hardcode a list, then we would need to manually check that it was up to date. So I'm not sure this would be a wise decision long term. There is a bit of a hack that has been suggested: write a function that uses net.Pipe to do a TLS handshake with itself, and set the GetCertificate field of the tls.Config to a function that reports the supported cipher suites, and use those values in the tls.Config slice that we start the http/grpc servers with. But I would need to think this through a bit before deciding if it's worthwhile. Do you know of any clients that are actually using these old cipher suites to communicate with bazel-remote? If not, then maybe it's OK to live with these old cipher suites being supported but not used? — Reply to this email directly, view it on GitHub <#708 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJPTU2JIZG5H6M7AG7SB7MLYBK5NTAVCNFSM6AAAAAA56UCBESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRHAYDGNBWGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mostynb]

Would it be possible to expose ciphers as configuration? May you suggest more information on using tls.Config and how to use it?

The idea is that on startup you can run a TLS server on a net.Pipe connection, connect to it and read the server's supported cipher suites from the client side. Then you can stop the server and use the cipher suite values (maybe removing some of them) that were discovered when creating the tls.Config for the real server.

But the more I think about it, the less I like this idea. If the go security team doesn't make this easy to do, the less important it must be. And I want to avoid custom solutions when it comes to security.

We don't know any clients that are actually using these old cipher suites to communicate with bazel-remote but security team see this as an issue so we need to block it in one way or other at our end.

If you really want to block the use of these (unused?) cipher suites, I think there's a way to do it without modifications to bazel-remote: you can run bazel-remote without network access by using unix domain sockets, and place a TLS termination proxy in front of bazel-remote. Then you can configure your preferred TLS settings in that proxy server.

[tushar150]

Thank you for the help. We will look at how to proceed with this further. Is it possible to merge disabled TLS1 and Tls1.1 with the master branch and push/build the latest image on https://bazel.build/?. Thanks and Regards, Tushar

…

On Mon, 30 Oct 2023 at 13:36, Mostyn Bramley-Moore ***@***.***> wrote: Would it be possible to expose ciphers as configuration? May you suggest more information on using tls.Config and how to use it? The idea is that on startup you can run a TLS server on a net.Pipe connection, connect to it and read the server's supported cipher suites from the client side. Then you can stop the server and use the cipher suite values (maybe removing some of them) that were discovered when creating the tls.Config for the real server. But the more I think about it, the less I like this idea. If the go security team doesn't make this easy to do, the less important it must be. And I want to avoid custom solutions when it comes to security. We don't know any clients that are actually using these old cipher suites to communicate with bazel-remote but security team see this as an issue so we need to block it in one way or other at our end. If you really want to block the use of these (unused?) cipher suites, I think there's a way to do it without modifications to bazel-remote: you can run bazel-remote without network access by using unix domain sockets, and place a TLS termination proxy in front of bazel-remote. Then you can configure your preferred TLS settings in that proxy server. — Reply to this email directly, view it on GitHub <#708 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJPTU2L2FKXFCOQERIF7HFLYB5NXDAVCNFSM6AAAAAA56UCBESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGY3DSNZZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tushar150]

Is this pushed to the main branch already?

…

On Tue, 7 Nov 2023 at 19:38, tushar garg ***@***.***> wrote: Thank you for the help. We will look at how to proceed with this further. Is it possible to merge disabled TLS1 and Tls1.1 with the master branch and push/build the latest image on https://bazel.build/?. Thanks and Regards, Tushar On Mon, 30 Oct 2023 at 13:36, Mostyn Bramley-Moore < ***@***.***> wrote: > Would it be possible to expose ciphers as configuration? May you suggest > more information on using tls.Config and how to use it? > > The idea is that on startup you can run a TLS server on a net.Pipe > connection, connect to it and read the server's supported cipher suites > from the client side. Then you can stop the server and use the cipher suite > values (maybe removing some of them) that were discovered when creating the > tls.Config for the real server. > > But the more I think about it, the less I like this idea. If the go > security team doesn't make this easy to do, the less important it must be. > And I want to avoid custom solutions when it comes to security. > > We don't know any clients that are actually using these old cipher suites > to communicate with bazel-remote but security team see this as an issue so > we need to block it in one way or other at our end. > > If you really want to block the use of these (unused?) cipher suites, I > think there's a way to do it without modifications to bazel-remote: you can > run bazel-remote without network access by using unix domain sockets, and > place a TLS termination proxy in front of bazel-remote. Then you can > configure your preferred TLS settings in that proxy server. > > — > Reply to this email directly, view it on GitHub > <#708 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AJPTU2L2FKXFCOQERIF7HFLYB5NXDAVCNFSM6AAAAAA56UCBESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGY3DSNZZGU> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[mostynb]

Sorry for the delay- I decided to add a flag to specify this value. This feature has landed on the master branch now, and been pushed to dockerhub and quay.io under the "latest" tag.

[tushar150]

Thanks a lot.

…

On Sun, 3 Dec, 2023, 19:46 Mostyn Bramley-Moore, ***@***.***> wrote: Sorry for the delay- I decided to add a flag to specify this value. This feature has landed on the master branch now, and been pushed to dockerhub and quay.io under the "latest" tag. — Reply to this email directly, view it on GitHub <#708 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJPTU2NCBUKJVGV5YDLAPU3YHSCTLAVCNFSM6AAAAAA56UCBESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGQ4TMNZTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>