Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#17870 closed defect (fixed)

Some Windows 10 users experience authenticode errors if Tor Browser is signed on Linux

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-security, TorBrowserTeam201601, GeorgKoppen201601
Cc: Actual Points:
Parent ID: #15538 Points:
Reviewer: Sponsor:

Description

There are users (like the one in https://blog.torproject.org/blog/tor-browser-505-released#comment-141808) that experience authenticode errors when trying to install a Tor Browser signed on a Linux system instead of a Windows one. It works fine for me and others on Windows 7, 8 and 10, though.

Child Tickets

Change History (13)

comment:1 Changed 4 years ago by gk

For anybody who is seeing this: what is shown as different in the certificate for 5.0.5 compared to 5.0.4 (apart from the timestamp) if one is inspecting the cert by right-clicking on the .exe and choosing "Properties"?

comment:2 Changed 4 years ago by cypherpunks

Missed intermediate certificate for 5.0.5?

--- sig504t.txt
+++ sig505t.txt

-subject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert EV Code Signing CA (SHA2)
-issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

comment:3 Changed 4 years ago by gk

Hm, that might be the issue. How did you create that diff? Extracting the signatures with osslsigncode does not show me these differences.

comment:4 Changed 4 years ago by cypherpunks

This is handmade by reducing diff for certs output by openssl pkcs7 -inform DER -in authenticode_extracted_from_exe -print_certs

comment:5 Changed 4 years ago by cypherpunks

Modern version of osslsigncode allows to specify -ac <crosscertfile>, is that something allows to append intermediate certificate to chain?

comment:6 Changed 4 years ago by cypherpunks

To prepare chain before sign:

--- AuthenticodeSigning.orig
+++ AuthenticodeSigning

 - convert it to PEM: openssl x509 -in tpo_cert.der -inform der -outform pem \
                      -out tpo_cert.crt
+....
+Get intermediate certificate from eToken or somewhere,
+(https://www.digicert.com/CACerts/DigiCertEVCodeSigningCA-SHA2.crt)
+then if it's in DER format
+....
+- convert to PEM: openssl x509 -in DigiCertEVCodeSigningCA-SHA2.crt \
+                  -inform der -outform pem -out middle_cert.crt
+- append: cat middle_cert.crt >> tpo_cert.crt
+

comment:7 Changed 4 years ago by gk

Keywords: TorBrowserTeam201512 added

comment:8 Changed 4 years ago by gk

Keywords: GeorgKoppen201512 added

comment:9 Changed 4 years ago by gk

Keywords: TorBrowserTeam201601 added; TorBrowserTeam201512 removed

Tickets for Jan 2016.

comment:10 Changed 4 years ago by gk

Keywords: GeorgKoppen201601 added; GeorgKoppen201512 removed

comment:11 in reply to:  6 Changed 4 years ago by gk

Resolution: fixed
Status: newclosed

Replying to cypherpunks:

To prepare chain before sign:

--- AuthenticodeSigning.orig
+++ AuthenticodeSigning

 - convert it to PEM: openssl x509 -in tpo_cert.der -inform der -outform pem \
                      -out tpo_cert.crt
+....
+Get intermediate certificate from eToken or somewhere,
+(https://www.digicert.com/CACerts/DigiCertEVCodeSigningCA-SHA2.crt)
+then if it's in DER format
+....
+- convert to PEM: openssl x509 -in DigiCertEVCodeSigningCA-SHA2.crt \
+                  -inform der -outform pem -out middle_cert.crt
+- append: cat middle_cert.crt >> tpo_cert.crt
+

Thanks, this seems to work. 5.5a6 will be signed this way.

comment:12 Changed 4 years ago by tom

I tested this on Windows 10 and had no issues, as seen here: http://i.imgur.com/vAi7xQS.png

When I run it, it still gives the "Do you want to run this file?" prompt, but this is because it's a downloaded executable. the Publisher shows the correct name. I don't believe there's anything Tor can do about this prompt. (The only thing might be to submit it to Windows for additional scanning or something - but I'm not sure and I can't find any indication that this is an option - it's hard to search for.)

I will note that the application is signed with SHA-1, which may cause issues down the road. It would be better to dual-sign it with SHA-256 _and_ SHA-1. (We're not an MSI, which causes problems, but .exes can be dual-signed. I don't know how to do this on linux, but there are instructions for Windows here: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx ).

SHA-256 will be untrusted as a signing algorithm in the future. According to MSFT's timetable, it looks like "On Win 7 and above, blocked on 1/1/2020 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files." Additionally as time goes on it may be more difficult to obtain a SHA-1 signing cert. I don't think "Mark of the Web" will affect Tor, but in the unlikely situation we wanted someone running a 4-year-old executable, the signature will be untrusted in four years.

comment:13 in reply to:  12 Changed 4 years ago by gk

Replying to tom:

I tested this on Windows 10 and had no issues, as seen here: http://i.imgur.com/vAi7xQS.png

When I run it, it still gives the "Do you want to run this file?" prompt, but this is because it's a downloaded executable. the Publisher shows the correct name. I don't believe there's anything Tor can do about this prompt. (The only thing might be to submit it to Windows for additional scanning or something - but I'm not sure and I can't find any indication that this is an option - it's hard to search for.)

Thanks.

I will note that the application is signed with SHA-1, which may cause issues down the road. It would be better to dual-sign it with SHA-256 _and_ SHA-1. (We're not an MSI, which causes problems, but .exes can be dual-signed. I don't know how to do this on linux, but there are instructions for Windows here: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx ).

SHA-256 will be untrusted as a signing algorithm in the future. According to MSFT's timetable, it looks like "On Win 7 and above, blocked on 1/1/2020 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files." Additionally as time goes on it may be more difficult to obtain a SHA-1 signing cert. I don't think "Mark of the Web" will affect Tor, but in the unlikely situation we wanted someone running a 4-year-old executable, the signature will be untrusted in four years.

This is a bit complicated. See the bug where Mozilla wrestled with it: https://bugzilla.mozilla.org/show_bug.cgi?id=1079858 (for a summary see comments 196 and 197). So, we are doing the same as Mozilla right now: SHA-1 signature with a SHA-2 code signing certificate. I've created #18287 for taking a switch to a SHA-2 signature into account.

Note: See TracTickets for help on using tickets.