Using FIPS-compliant boring Go to connect to microsoft.com(specifically)

400 views
Skip to first unread message

mohit.b...@gmail.com

unread,
Apr 30, 2020, 2:13:18 PM4/30/20
to golang-nuts

Summary - Trying Boring Go in FIPS mode to connect to Microsoft services (Azure). Intermediate CA Certificate for Microsoft has a 4096 bit public key that is not allowed by Boring Go (Code here ), Is there any workaround without having to turn off FIPS mode ?

go version go1.14b4 linux/amd64

Hi all,
So I am working on an application that requires to be run in FIPS mode and has to connect to Azure services. I looked up the boring Go branch, got version 1.14 and started using it.
While trying to connect to Azure services (for eg. graph[dot]microsoft[dot]com or even microsoft[dot]com), I was getting an incompatible certificate usage issue. Here is the sample code I am using -
`package main

import (
        "fmt"
        "io/ioutil"
        "net/http"
        _ "crypto/tls/fipsonly" //Code works without this but we need the application to run in FIPS
)
func main() {
        url := "https: //microsoft.com" //Space put here because of two link limit
        fmt.Printf("HTML code of %s ...\n", url)
        client := &http.Client{}
        resp, err := client.Get(url)
        
        if err != nil {
                panic(err)
        }
       
        defer resp.Body.Close()
        
        html, err := ioutil.ReadAll(resp.Body)
        if err != nil {
                panic(err)
        }
        
        fmt.Printf("%s\n", html)
}`

The error I get is as follows -
HTML code of https: //microsoft.com ... panic: Get "https: //microsoft.com": x509: certificate specifies an incompatible key usage goroutine 1 [running]: main.main() /usr/local/go/bin/test.go:15 +0x26c exit status 2

I checked the golang code and found that a certificate with a 4096 bit public key is not a valid certificate according to the IsBoringCertificate function The intermediate certificate in Microsoft’s Certificate Chain has a 4096 bit public key.

Screen Shot 2020-04-27 at 12.35.20 PM

So, my question is as follows :

  1. Is this intended behavior ?
  2. If yes, is here any workaround via which I can keep FIPS mode on and connect to these services ? This workaround can be code changes or using different tools. However, I can’t turn off FIPS mode.

Thanks for going through this !

David Anderson

unread,
Apr 30, 2020, 2:31:37 PM4/30/20
to mohit.b...@gmail.com, golang-nuts
(Disclaimer: not a FIPS compliance expert, you should hire your own experts to get authoritative answers)

FIPS 140-2 seems to reference FIPS 186-4 for specific algorithm choices. FIPS 186-4 specifies that the RSA modulus shall be 1024, 2048, or 3072 bits. So, as-written, it seems like 4096-bit RSA keys are not allowed under FIPS 140-2, which would explain why BoringCrypto doesn't permit them.

There seems to be a bunch of discussion in standards bodies saying that this was a bit of a mistake in FIPS 186-4, but the great thing about regulations is you don't fix them just by saying "oh, that's obviously incorrect, let's just ignore it" :(

Seems like you need to talk to Azure about FIPS 140-2 compliant access methods, or to your own compliance staff about how you can navigate the regulatory requirements and still connect to stuff.

- Dave

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/619f65bc-e79a-4412-8913-a03992fae04a%40googlegroups.com.

mohit.b...@gmail.com

unread,
May 3, 2020, 4:48:26 PM5/3/20
to golang-nuts
Thanks, it looks like we have some work to do !


On Thursday, April 30, 2020 at 11:31:37 AM UTC-7, David Anderson wrote:
(Disclaimer: not a FIPS compliance expert, you should hire your own experts to get authoritative answers)

FIPS 140-2 seems to reference FIPS 186-4 for specific algorithm choices. FIPS 186-4 specifies that the RSA modulus shall be 1024, 2048, or 3072 bits. So, as-written, it seems like 4096-bit RSA keys are not allowed under FIPS 140-2, which would explain why BoringCrypto doesn't permit them.

There seems to be a bunch of discussion in standards bodies saying that this was a bit of a mistake in FIPS 186-4, but the great thing about regulations is you don't fix them just by saying "oh, that's obviously incorrect, let's just ignore it" :(

Seems like you need to talk to Azure about FIPS 140-2 compliant access methods, or to your own compliance staff about how you can navigate the regulatory requirements and still connect to stuff.

- Dave

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

Bhagya Prasad NR

unread,
May 3, 2020, 11:10:37 PM5/3/20
to golang-nuts
(Disclaimer: Not a FIPS compliance expert)

Couple of observations. I looked at how others are treating this by taking an example of OpenSSL 1.1.1 and Go's 1.12.4 distribution from CentOS 8.1 (which is derived from RHEL 8.1 and RHEL is inline for FIPS 140-2 validation as we speak). 

[1]. OpenSSL 1.1.1 FIPS patch (source: http://vault.centos.org/8.1.1911/BaseOS/Source/SPackages/openssl-1.1.1c-2.el8.src.rpm ) allows RSA public key modulus bits greater than 1024 bits in size via OPENSSL_RSA_FIPS_MIN_MODULUS_BITS (whose value is defined in rsa.h as 1048)


[2]. CentOS 8.1 's go lang distribution (source: http://vault.centos.org/8.1.1911/AppStream/Source/SPackages/golang-1.12.12-4.module_el8.1.0+271+e71148fc.src.rpm; File: src/crypto/tls/boring.go) allows RSA public key modules bits greater than 2048 and its size divisible by 512 as valid RSA public keys.


Attaching relevant screenshots below.  Does this tell there is a need for a patch in golang's dev.boringcrypto branch to allow RSA 4096 bit keys?  Has anyone encountered the issue by using dev.boringcrypto distribution?

Thanks!
Bhagya

pradee...@gmail.com

unread,
May 4, 2020, 11:32:08 AM5/4/20
to golang-nuts
We are facing similar issues with dev.broingCrypto branch when using RSA 4096. 


Question/Problem SP 800-131A Rev1 provides only the lower bound, 2048 bits, for the RSA modulus size used in signature generation. Does this imply that the RSA modulus sizes other than 2048 and 3072 may be used to generate the RSA signatures in the approved mode? In particular, is the use of the 4096-bit modulus approved and, if so, what are the testing requirements for the RSA key generation if the key pair used in the RSA signature algorithm is generated by the module?

Resolution

When performing an RSA signature generation, a module may use any modulus size greater than or equal to 2048 bits. At least one of the RSA modulus lengths supported by the module for RSA signature generation shall be 2048, 3072, or 4096 bits.

Bhagya Prasad NR

unread,
May 4, 2020, 1:22:39 PM5/4/20
to golang-nuts
(Disclaimer: Not a FIPS compliance expert)

Here's NIST position - https://csrc.nist.rip/groups/STM/cmvp/notices.html . As per the document "At least one of the RSA modulus lengths supported by the module for RSA signature generation shall be 2048, 3072, or 4096 bits. The RSA signature algorithm implementations shall be tested by a CST lab for all implemented RSA modulus lengths where CAVS testing is available.". As of last month such a testing to validate RSA 4096 bit keys is available is being tested (scroll down to RSA section) - https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?product=12388 .

In summary dev.boringcrypto needs a fix to honor RSA 4096 bit keys to the least and reject anything less than 2048 bits. This will certainly benefit the projects using dev.boringcrypto and looking for FIPS validation.

Regards,
Bhagya

David Anderson

unread,
May 4, 2020, 3:56:12 PM5/4/20
to Bhagya Prasad NR, golang-nuts
The next step then is to file a bug on Github to discuss this. That way you'll get an authoritative answer from boringcrypto's devs, one way or the other (authoritative in the sense of "yes we will take such a patch/no we won't take such a patch", not authoritative in the sense of "yes this is definitely FIPS-140-2 compliant").

- Dave

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b460994e-4be3-42ca-9e03-6ee7ad1238de%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages