U2F registration returns NotTrustedAnchor

[Jellyfrog]

When registering an U2F key (Yubikey) server fails with Error: NotTrustedAnchor, which seems to come from here: https://github.com/wisespace-io/u2f-rs/blob/193de35093a44576edba6cc94d9b54f2a1cbdcd1/src/register.rs#L50
At first I thought it was the reverse proxy, but same result using it directly with Rocket.

bitwarden_rs @ 0f6ab01f777700c68aee8fcf0cbf0be742c286e1
web-vault @ v2.5.0
FreeBSD 11.2-RELEASE-p5

Config

DOMAIN=https://site:8000
ROCKET_TLS={certs="/usr/local/etc/letsencrypt/live/site/fullchain.pem",key="/usr/local/etc/letsencrypt/live/site/privkey.pem"}

Log:

POST /api/two-factor/get-u2f application/json; charset=utf-8:
    => Matched: POST /api/two-factor/get-u2f
    => Outcome: Success
    => Response succeeded.
GET /images/4.png image/webp:
    => Matched: GET /<p..>
    => Outcome: Success
    => Response succeeded.
POST /api/two-factor/get-u2f-challenge application/json; charset=utf-8:
    => Matched: POST /api/two-factor/get-u2f-challenge
    => Outcome: Success
    => Response succeeded.
GET /app-id.json:
    => Matched: GET /app-id.json
    => Outcome: Success
    => Response succeeded.
PUT /api/two-factor/u2f application/json; charset=utf-8:
    => Matched: PUT /api/two-factor/u2f
Error: NotTrustedAnchor
ERROR: Error activating u2f
    => Outcome: Success
    => Response succeeded.

PUT request returns:

{"ErrorModel":{"ExceptionMessage":null,"ExceptionStackTrace":null,"InnerExceptionMessage":null,"Message":"Error activating u2f","Object":"error","ValidationErrors":null},"error":"unknown_error","error_description":"unknown_error"}

[Jellyfrog]

This is probably due to broken certs in the key;
briansmith/webpki#34 (comment)
tstranex/u2f#8 (comment)

Will try to verify if this is the case.

[dani-garcia]

Seeing as this is a problem for more people, I'm looking into a possible solution. Checking the other libraries that already deal with this issue, I published a new branch that should hopefully detect it (but not fix it, for now):

https://github.com/dani-garcia/bitwarden_rs/tree/trustanchor-fix

Running this should print in the console something like:

CERT HASH: [34, 9B, CA, 10, 31, F8, C8, 2C, 4C, EC, A3, 8B, 9C, EB, F1, A6, 9D, F9, FB, 3B, 94, EE, D9, 9E, B3, FB, 9A, A3, 82, 2D, 26, E8]

And if it detected the cert as one of the broken ones, it would also print Detected broken cert, fixing... (It won't fix anything yet, I want to make sure this is the right way first).

@mprasil Can you get a docker image built, so those using docker can test this issue?

@neoautomata, @Jellyfrog can you check this branch and see if it detects the issue?

[Jellyfrog]

Weirdest thing, I can now register my key.
Will try later on my other laptop where it didn't work...

[2019-01-22 11:10:07][_][INFO] Matched: PUT /api/two-factor/u2f (activate_u2f_put)                                                  
CERT HASH: [A9, F0, A1, 12, DF, 24, 28, 84, AE, 6E, 62, 88, E7, C2, C7, 2D, 8D, 2B, FA, 74, 4B, 5, ED, 76, 7E, 3E, 9E, 30, EC, A, 77, 5A]
[2019-01-22 11:10:08][_][INFO] Outcome: Success
[2019-01-22 11:10:08][_][INFO] Response succeeded.

[mprasil]

The image is just being built, give it about an hour and then you can use mprasil/bitwarden:trustanchor-fix to test it.

[neoautomata]

Using that Image I get the following in the server logs:

[2019-01-22 19:01:47][_][INFO] Matched: PUT /api/two-factor/u2f (activate_u2f_put)
CERT HASH: [8C, 5E, 42, B, 9E, 67, 3B, 39, D7, DB, F4, 2A, 3D, 82, 8C, C5, 8, 4B, D4, 98, 7F, 72, 5F, 2C, 8F, 1B, 64, 4, D9, D4, 27, B0]
[2019-01-22 19:01:47][bitwarden_rs::error][ERROR] U2fError.
[CAUSE] NotTrustedAnchor
[2019-01-22 19:01:47][_][INFO] Outcome: Success
[2019-01-22 19:01:47][_][INFO] Response succeeded.

[neoautomata]

My other key has a different hash:

[2019-01-22 19:05:03][_][INFO] Matched: PUT /api/two-factor/u2f (activate_u2f_put)
CERT HASH: [84, 7E, D3, 2D, 86, E1, 11, F6, 6D, 72, 54, 21, C3, 17, 4, 5C, 4F, 4B, 61, 4C, 2C, 45, FA, F3, 36, CA, 61, 81, C9, AE, 12, 99]
[2019-01-22 19:05:03][bitwarden_rs::error][ERROR] U2fError.
[CAUSE] NotTrustedAnchor
[2019-01-22 19:05:03][_][INFO] Outcome: Success
[2019-01-22 19:05:03][_][INFO] Response succeeded.

[Jellyfrog]

Weirdest thing, I can now register my key.
Will try later on my other laptop where it didn't work...

[2019-01-22 11:10:07][_][INFO] Matched: PUT /api/two-factor/u2f (activate_u2f_put)                                                  
CERT HASH: [A9, F0, A1, 12, DF, 24, 28, 84, AE, 6E, 62, 88, E7, C2, C7, 2D, 8D, 2B, FA, 74, 4B, 5, ED, 76, 7E, 3E, 9E, 30, EC, A, 77, 5A]
[2019-01-22 11:10:08][_][INFO] Outcome: Success
[2019-01-22 11:10:08][_][INFO] Response succeeded.

Same key, different computer:

CERT HASH: [D6, F8, 36, 36, 27, 28, 9D, 4E, AD, F5, 92, 12, 61, 46, 2F, D8, 3D, EF, 30, 0, BD, 3F, 29, 2F, 86, DF, 66, 42, FB, 87, 23, DA]
[2019-01-23 21:23:57][bitwarden_rs::error][ERROR] U2fError.
[CAUSE] NotTrustedAnchor

[Jellyfrog]

With Firefox it always works for me, and it returns the same cert each time:

CERT LEN: 561
CERT: b"0\x82\x02-0\x82\x01\x17\xa0\x03\x02\x01\x02\x02\x04\x05\xb6\x05y0\x0b\x06\t*\x86H\x86\xf7\r\x01\x01\x0b0.1,0*\x06\x03U\x04\x0
3\x13#Yubico U2F Root CA Serial 4572006310 \x17\r140801000000Z\x18\x0f20500904000000Z0(1&0$\x06\x03U\x04\x03\x0c\x1dYubico U2F EE Ser
ial 958150330Y0\x13\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\xfd\xb8\xde\xb3\xa1\xedp\xebcl\x06n\xb6\0i\x
....

With Chrome it returns different data each time and never works;

CERT LEN: 287                                                                                                                        
CERT: b"0\x82\x01\x1b0\x81\xc2\xa0\x03\x02\x01\x02\x02\n\x06\xd9\xe5* O8v8\x1f0\n\x06\x08*\x86H\xce=\x04\x03\x020\x151\x130\x11\x06\x
03U\x04\x03\x13\nU2F Issuer0\x1a\x17\x0b0001010000Z\x17\x0b0001010000Z0\x151\x130\x11\x06\x03U\x04\x03\x13\nU2F Device0Y0\x13\x06\x07
*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\x97\x98>\xc6qRR\xfee\xc7Y\xf3\x8d\xbaz\x84\xe7J\xae\xec\x06\xa1\xb0K#lH
...

CERT LEN: 287                                                                                                                        
CERT: b"0\x82\x01\x1b0\x81\xc2\xa0\x03\x02\x01\x02\x02\n \xc8^\xdb\xb3m\xdc\x89\x9e\x070\n\x06\x08*\x86H\xce=\x04\x03\x020\x151\x130\
x11\x06\x03U\x04\x03\x13\nU2F Issuer0\x1a\x17\x0b0001010000Z\x17\x0b0001010000Z0\x151\x130\x11\x06\x03U\x04\x03\x13\nU2F Device0Y0\x1
3\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04m\xdf\xce[\xef\xc7}A\xd3\xc2-\x10e\xdcH\xe2-\x17\xc68}R\t\x8a\\
...

Note the different cert length also.

[dani-garcia]

This should have been fixed now in 9d027b9, hopefully.

[neoautomata]

Just pulled down :latest and I was able to register one of my keys, but not the other. I think it's the second hash above which didn't work. It does work on Github, so I don't think it's the key.

[dani-garcia]

Do you still get the NotTrustedAnchor error, or is it something different this time?

[neoautomata]

Yes, same NotTrustedAnchor error. I also got a pop up from chrome asking to read make and model of the key, which I've never seen on any site before.

[dani-garcia]

The popup is expected, it's to avoid Chrome from sending us self-signed certificates instead of the devices actual certificate.

Can you tell me what do you get now running the :trustanchor-fix image with both keys? (Make sure to pull it to use the newest one)

[neoautomata]

Sorry it has taken me a bit to respond, was out of town.

Here's the error from the lastest trustanchor-fix image:

[2019-02-03 13:17:08][_][INFO] Matched: PUT /api/two-factor/u2f (activate_u2f_put)
CERT LEN: 326
UNUSED BITS: 30
CERT: b"0\x82\x01B0\x81\xea\xa0\x03\x02\x01\x02\x02\t\x01#3\xff\xff\xff\xffFX0\n\x06\x08*\x86H\xce=\x04\x03\x020\x1b1\x190\x17\x06\x03U\x04\x03\x13\x10Gnubby HSM CA 000\"\x18\x0f20120601000000Z\x18\x0f20620531235959Z001\x190\x17\x06\x03U\x04\x03\x13\x10Google Gnubby v01\x130\x11\x06\x03U\x04-\x03\n\0\x01#3\xff\xff\xff\xffFX0Y0\x13\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\xc1\xc4\xd0&>Q\xdd)I\x8f\x8b\x8a\x85\xfa\xea\xb5\x04\x9bh\x16c\x953c\xdd\xbf/\xe2\xca%\x10\xcf\xcf\xd33|\xb8\x0eF\x1a\x05$\x08#\x8d\x19\x95\xb3\xdb\x0b\x98\xe5\x1e1\n4si\xc7t\x9b\xf7\x94G0\n\x06\x08*\x86H\xce=\x04\x03\x02\x03G\00D\x02 \x1cn\ts\x03\xac\xe9\xb9z\xfa\xf4I\xcaT<\xafv'\xdf\xd4[\x90E\xda,z\xe2TG\xa9jn\x02 Sf\xd3\x9a\x92\x9af\xba\xae\xe4\xc9\xcd\xd1\xcd\xf8\xe9\x9b\x97\xa1\x19\x83M6+\xf9\xcd\x10\xd3B\x0e\xae]"
B64 ENCODED: "MIIBQjCB6qADAgECAgkBIzP/////RlgwCgYIKoZIzj0EAwIwGzEZMBcGA1UEAxMQR251YmJ5IEhTTSBDQSAwMDAiGA8yMDEyMDYwMTAwMDAwMFoYDzIwNjIwNTMxMjM1OTU5WjAwMRkwFwYDVQQDExBHb29nbGUgR251YmJ5IHYwMRMwEQYDVQQtAwoAASMz/////0ZYMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwcTQJj5R3SlJj4uKhfrqtQSbaBZjlTNj3b8v4solEM/P0zN8uA5GGgUkCCONGZWz2wuY5R4xCjRzacd0m/eURzAKBggqhkjOPQQDAgNHADBEAiAcbglzA6zpuXr69EnKVDyvdiff1FuQRdoseuJUR6lqbgIgU2bTmpKaZrqu5MnN0c346ZuXoRmDTTYr+c0Q00IOrl0="
B64 DECODED: Err(InvalidByte(1, 130))
CERT HASH: [DA, 5B, E, D6, C9, 45, 74, DC, C0, 63, D4, ED, C2, D0, DE, 9E, 66, 6E, B2, 14, FE, 62, 9D, 2C, C9, 2B, CB, 1E, 1, 79, 6C, 6F]
[2019-02-03 13:17:08][bitwarden_rs::error][ERROR] U2fError.
[CAUSE] NotTrustedAnchor

[dani-garcia]

Okay, with some more testing using that cert, I found the cause of the problem, the cert doesn't have an extensions field with a SubjectAltName, and webpki requires it, there is a recent bug about it here: briansmith/webpki#90. This makes sense for SSL certificates, which is what the library was made for, but apparently some U2F devices don't have those required values.

There is a pending issue for U2F attestation support that mentions that change, but it hasn't seen activity in a while: briansmith/webpki#57.

I'm not sure there is something we can do here for now, and I don't think it would be particularly safe for us to try to add a random SubjectAltName whenever we get an error.

[yacoob]

Just bumped into this. The weirdest thing is, I've only seen this upon trying to add a second key to my account - which is weird, as I somehow was able to add the first one :D

Just to make sure I get the whole picture: does this effectively preclude usage of fido u2f until the referenced bugs are resolved?