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

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.

added GeorgKoppen201601 TorBrowserTeam201601 component::applications/tor browser owner::tbb-team parent::15538 priority::high resolution::fixed severity::major status::closed tbb-security type::defect labels

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"?

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

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

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

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

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
+

Trac:
Keywords: N/A deleted, TorBrowserTeam201512 added

Trac:
Keywords: N/A deleted, GeorgKoppen201512 added

Tickets for Jan 2016.

Trac:
Keywords: TorBrowserTeam201512 deleted, TorBrowserTeam201601 added

Trac:
Keywords: GeorgKoppen201512 deleted, GeorgKoppen201601 added

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.

Trac:
Resolution: N/A to fixed
Status: new to closed

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.

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 (moved) for taking a switch to a SHA-2 signature into account.

closed

mentioned in issue #18287 (moved)

moved to tpo/applications/tor-browser#17870 (closed)

mentioned in issue tpo/applications/tor-browser#18287 (closed)