Search Search within:  All issues  Open issues  New issues  Issues to verify for
 Issue 72041: Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error instead of PIN1 prompt 8 people starred this issue and may be notified of changes. Back to list
Status: Verified rsleevi@chromium.org Feb 2011 wtc@chromium.org, rsleevi@chromium.org

Restricted
• Only users with EditIssue permission may comment.

Chrome Version       : 9.0.597.84 (Official Build 72991)
URLs (if applicable) : http://www.eesti.ee/portaal/portaal.sisene?level=21&loc=/est/, https://id.swedbank.ee/private/home/start
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 3.x:
IE 7/8:

What steps will reproduce the problem?
1. Insert your Estonian ID card into the Smartcard reader
2. Access http://www.eesti.ee/portaal/portaal.sisene?level=21&loc=/est/
3. Browser prompts for the certificate
4. Select the authentication certificate
5. Wait for the PIN 1 prompt

What is the expected result?
Browser should prompt for PIN 1 for authentication and display your name to indicate successful authentication.

Error message is displayed: Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error

Please provide any additional information below. Attach a screenshot if
possible.
The authentication got broken after upgrading to Google Chrome Version 9 (stable) on Windows 7. The authentication used to work on all previous stable builds of Chrome on Windows.

Feb 4, 2011
(No comment was entered for this change.)

Labels: -Area-Undefined Area-Internals Internals-Network
Feb 5, 2011
Thanks for splitting off the Windows-specific details. I'm sorry to hear you're having trouble.

Can you attach a log obtained by
- Closing all existing tabs
- In a new tab, loading chrome://net-internals
- Click the link "Help: How to get data for bug reports?"
- Following those directions, visit one of the affected URLs from above
- Attach the net log generated to this report.

Thanks!

Cc: w...@chromium.org rsle...@chromium.org
Labels: OS-Windows
Feb 5, 2011
Here is the log. Hope it has all the necessary information.

Feb 5, 2011
Thanks. The error being reported internally indicates an issue trying to use the private key to sign data as part of the SSL handshake.

A few hours ago, I committed a series of changes to the Chromium trunk that improve the SSL client authentication functionality on Windows. These changes would directly affect the area that is reporting an error.

I'd be wondering if you'd be willing to try a Chromium snapshot, such as http://build.chromium.org/f/chromium/snapshots/chromium-rel-xp/73914/ , and reproduce the above steps and report back if it solves the problem / a new error code is returned.

Feb 5, 2011
I've tried the snapshot build (11.0.660.0 Developer Build 73914) and the new error code is:

Error 141 (net::ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED): Unknown error.

Would you like to get a new net-internals log as well?

Feb 5, 2011
ilya: Thanks for the quick response. My hope was that this was due to/related to  Issue 71748 , but unfortunately it looks to be a different cause.

A new net-internals log isn't needed at this point. It looks like this may block until we can get one or more test cards, as described on  Issue 44075 , but I'll continue looking for possible causes.

Feb 5, 2011
Would it be possible to see what has changed in the particular module in the version 9 stable release, since the authentication has been working perfectly in all of the previous versions?

Feb 5, 2011
ilya: Sure, I just realized that one useful flag wasn't mentioned here or on 44075.

In Chrome 9+, a new SSL backend is being used that has greater support for new and emerging standards, plus a substantially quicker turn-around for critical security issues. This backend was used since Chrome 6 for all situations but client authentication, but in Chrome 9, it's now being used for client authentication as well. Attempts were made to emulate some of the subtleties of the OS-libraries, but at the same time, the implementation sought to follow the published documentation from the OS vendors.

You can pass the command-line flag "--use-system-ssl" to revert to the Chrome 5 behaviour, where the system libraries (SChannel on Windows, Secure Transport on Mac) are used for all SSL connections.

You can find detailed instructions about how to enable command-line flags at http://www.chromium.org/for-testers/enable-logging - just substitute the logging flags from that document with the above flag.

Hopefully the above will work as a temporary solution. Long term, the goal is to get the PIN1 prompt working when using the new backend.

Can you provide a little bit of information about the middle-ware you're using for your smart card? Are you using the installer from https://installer.id.ee/ ?

Feb 5, 2011
ilya: While I still continue investigating, I was hoping you could confirm that the prompt is indeed showing your authentication certificate and not your signing certificate. I want to ensure that the correct certificate is being filtered, as it will fail if we're showing/you're selecting the signing certificate. There was a bug a few months ago about the certificate prompt selecting the wrong certificate, so I wanted to make sure there wasn't a regression/variation of that.

Feb 5, 2011
The --use-system-ssl flag works like a charm. Thank you for that!

The middleware I'm using is from the link you mentioned. There is actually a new version of the middleware currently in development but as far as I know the authentication fails with the new SSL backend as well.


Feb 5, 2011
I've also checked to make sure the prompt shows the correct authentication certificate with the new SSL backend and I can confirm that it does indeed. Tested on both the latest 9.x stable and 11.x snapshot versions.

Feb 7, 2011
If you would like to order an Estonian test ID-card you should be able to get all the relevant information here: info@sk.ee

Feb 7, 2011
ilya.shmorgun: are you or anyone you know able to build
Chrome from source code and debug it in Visual Studio?

rsleevi: should we add logging statements to ssl3_PlatformSignHashes
to help us track down which CryptoAPI function fails, and what the
GetLastError() error code is?  We may need to resort to writing
(with fprintf calls) to a hardcoded log file, say C:\ee-debug.txt.

Status: Assigned
Owner: rsle...@chromium.org
Labels: Mstone-11
Feb 7, 2011
wtc: I was thinking the same thing. Since we're in Chromium-in-NSS code, I was going to add an error callback function that would then dump VLOG(1).

From looking at the 3.2 sourceof the id.ee middleware, my hunch is that the CRYPT_NOHASHOID with SSL3_SHAMD5 may be the cause. One of the things I noticed with SChannel on XP when looking into  Issue 71928  was that SChannel was passing 0 for dwFlags. However, I haven't had a chance to run this through and see how some of the other CSPs (including Base Minidriver) behave.

Feb 7, 2011
rsleevi: how do I download the id.ee middleware source code?
I'd like to take a look, too.

We should be able to pass CRYPT_NOHASHOID to CryptSignHash.

Another possibility is that we need to call CryptAcquireContext
using the PROV_RSA_SCHANNEL for CALG_SSL3_SHAMD5.  See
http://msdn.microsoft.com/en-us/library/aa388168(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa387710(v=VS.85).aspx

Once we know which CryptoAPI call fails, we'll have a bettter
idea what we do wrong.  I won't be surprised if it's the
CryptGetHashParam(HP_HASHSIZE) call that fails.

Feb 7, 2011
wtc: https://svn.eesti.ee/projektid/idkaart_public/3.2/ is the source link. It's what is recommended for Mac/Linux, and I believe the goal is to use it on Windows.

The CRYPT_NOHASHOID comment is based on https://svn.eesti.ee/projektid/idkaart_public/3.2/esteid-csp/csp_tool/csp_tool.cpp - note the test harness (testsign/allsign) that tests SSL signing passes 0 for dwFlags. This matches what I saw SChannel doing.

As for CryptGetHashParam, it appears the CSP eats the result code when it forwards the request into the underlying CSP - see https://svn.eesti.ee/projektid/idkaart_public/3.2/esteid-csp/Csp_Hash.cpp - so I wouldn't anticipate any errors with the underlying CSP to be bubbled up by the EE CSP.

While it is wrapping MS_ENHANCED_PROV/PROV_RSA_FULL to do the actual hashing, that should be the same CSP as PROV_RSA_SCHANNEL, and should support the same algs.

I suppose the next step would be to add diagnostic logging back for the CSP - PP_CONTAINER, PP_IMPTYPE, PP_NAME, PP_PROVTYPE, and PP_VERSION.

Also, the means of finding that link (since I'm always losing the link trail) - http://www.id.ee/blog_en/?p=23 to http://id.eesti.ee/ to https://svn.eesti.ee/projektid/idkaart_public/3.2 (Note: This is the version under the link "Would you like to try new software" at http://installer.id.ee

Feb 8, 2011
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=74254

------------------------------------------------------------------------
r74254 | rsleevi@chromium.org | Tue Feb 08 21:42:37 PST 2011

Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ssl/sslplatf.c?r1=74254&r2=74253&pathrev=74254

Do not pass CRYPT_NOHASHOID to CryptSignHash with CALG_SSL3_SHAMD5.
This may fix  bug 72041 .

R=wtc
BUG=72041
TEST=covered by existing net_unittests

Review URL: http://codereview.chromium.org/6458023
------------------------------------------------------------------------

Feb 9, 2011
ilya.shmorgun: please try this Chromium snapshot:
http://build.chromium.org/f/chromium/snapshots/chromium-rel-xp/74254/

I will try to write a small test program for you to get more

rsleevi: I attached the csp.cpp file from Coolkey CSP
(http://www.directory.fedora.redhat.com/wiki/CoolKey#Windows_CSP).

Its CPSignHash function ignores CRYPT_NOHASHOID when hashAlg is
CALG_SSL3_SHAMD5.  This shows CRYPT_NOHASHOID only applies to
CALG_MD5 and CALG_SHA1, which have OIDs.  Its hash functions
simply delegate to the built-in Microsoft CSP, so our
CryptGetHashParam(HP_HASHSIZE) call should not fail, even
though it is not in the procedure described by MSDN:
http://msdn.microsoft.com/en-us/library/aa379865(v=vs.85).aspx

Feb 9, 2011
The authentication seems to be working in the 11.0.665.0 (Developer Build 74254) version. Would you like me to do some additional testing, maybe with the test program you mentioned?

Feb 9, 2011
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=74375

------------------------------------------------------------------------
r74375 | wtc@google.com | Wed Feb 09 15:25:46 PST 2011

Changed paths:
M http://src.chromium.org/viewvc/chrome/branches/648/src/net/third_party/nss/ssl/sslplatf.c?r1=74375&r2=74374&pathrev=74375

Merge 74254 - Do not pass CRYPT_NOHASHOID to CryptSignHash with CALG_SSL3_SHAMD5.
This may fix  bug 72041 .

R=rsleevi
BUG=72041
TEST=covered by existing net_unittests
Review URL: http://codereview.chromium.org/6478008
------------------------------------------------------------------------

Feb 9, 2011
ilya.shmorgun: the test program and its source code are attached.

It is best if you compile the test program yourself.  Open a
Visual Studio Command Prompt and type the command

cl /EHsc /W3 ClientCert.cc

to compile the test program.  If you use the executable I
provided, please scan it with anti-virus software.

Please run the test program

.\ClientCert.exe

and post the output here.  Thanks.

Feb 10, 2011
Here is the output from the test program. It shows the window for choosing the  certificate but doesn't give me the ability to enter the PIN for the procedure to work.

.\ClientCert.exe
First CryptSignHash failed: 0x80090009
SignHashes failed

Feb 10, 2011
ilya.shmorgun: the error code 0x80090009 is NTE_BAD_FLAGS.  This
confirms that passing the CRYPT_NOHASHOID flag to CryptSignHash
was the problem.  I attached a new version of the test program
in which the two occurrences of CRYPT_NOHASHOID were changed to 0.

Please compile it with the command

cl /EHsc /W3 ClientCert1.cc

and run it with the command

.\ClientCert1.exe

It should allow you to enter the PIN, and print "PASS".

Please submit a bug report for the Estonian ID CSP.  It should
allow the CRYPT_NOHASHOID flag to be used with the hash algorithm
CALG_SSL3_SHAMD5.  I found that Microsoft documentation is incorrect
about the NTE_BAD_FLAGS error code for CPSignHash.  Both the
CryptSignHash and CPSignHash MSDN pages say in the return code table:

NTE_BAD_FLAGS  The dwFlags parameter is nonzero.

http://msdn.microsoft.com/en-us/library/aa380280(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa379859(VS.85).aspx

Perhaps that's why the author of the Estonian ID CSP disallows
the CRYPT_NOHASHOID flag.

Status: Started
Labels: -Mstone-11 Mstone-9 ReleaseBlock-Stable
Feb 11, 2011
Yes, everything worked as expected and the output was indeed "PASS". I will pass the information about the bug to the Estonian ID-card development team.

So does this mean that the problem in Chrome is fixed?

Feb 11, 2011
ilya.shmorgun: Yes, the same logic included in the test from wtc's comment #26 will be included in the next major release of Chrome (11, as per comment #17). It's also been integrated into the Chrome 10 branch for the the next release of Chrome 10 (as per comment #22). I believe wtc will is also looking to include it for the next release of Chrome 9 (TBD, but this bug will also be updated with similar comments). In all of these releases, it should work fine without passing --use-system-ssl, restoring the intended behaviour. Thanks very much for helping to verify the fix.

One thing to consider is potentially installing the Chrome canary build. Chrome canary build is a great way for you to help us test the upcoming SSL changes: http://googlesystem.blogspot.com/2010/07/google-chrome-canary-build.html

The canary build is installed side by side; you still keep the stable build as the primary Chrome installation.

More work is still planned in this area, so the Canary build is a great way to help ensure there are no regressions with your particular smart card/middleware.

Feb 11, 2011
Are you planning on updating this issue once the fix is integrated in to the stable branch? Otherwise it may be difficult to learn that the issue is solved once an update to Chrome stable comes out.

Feb 11, 2011
Also I have installed Canary build 11.0.667.0 (Official Build 74431) but it seems that the fix is not yet working there.

Feb 11, 2011
I can confirm the issue on 9.0.597.98 (Win XP).

Feb 11, 2011
ilya.shmorgun: Canary build 11.0.667.0 (Official Build 74431) should
have the bug fix (r74254).  If it isn't working, then I'm in trouble.

ain.tohvri: could you also install and test the Canary build?

Status: WillMerge
Feb 11, 2011
I had the same problem on build 9.0.597.94 Win7 x64.
I downloaded and tried the canary build 11.0.667.0 and can confirm that it works for me now.

Feb 11, 2011
I have tested the Canary build 11.0.667.0 (Official Build 74431) on a different machine. While using the old version of ID-card middleware (1.5.72) the authentication was indeed successful. However with the new version 3.3 Chrome managed to let me select the certificate, enter the PIN1 code but then returned an Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Feb 11, 2011
The source code for the 3.3 version of the middleware is available here: https://svn.eesti.ee/projektid/idkaart_public/3.3/

Release notes are available here: http://support.sk.ee/eng/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1554 although these might be a bit out of date.

Feb 11, 2011
ilya.shmorgun: I believe the problem with the 3.3 version of the
middleware is a different bug.  We may want to open a new bug
report and focus this bug on the CRYPT_NOHASHOID bug.

Does the ClientCert1.exe test program work with the 3.3 version
of the middleware?

Please follow the instructions in comment 2 and attach a new
net-internals log file for the 3.3 version of the middleware.

Feb 11, 2011
I can confirm that 11.0.667.0 canary build (Win XP) doesn't have this issue and works as expected.

Feb 11, 2011
I have tried running ClientCert1.exe with the 3.3 version of the middleware and the result is PASS.

I'm not sure it makes sense to file a separate ticket because the error returned by the Chrome Canary build is still the same, but please let me know what you think of this.

Feb 11, 2011
ilya.shmorgun: thank you for running ClientCert1.exe.

Please follow the instructions in comment 2 and attach a new
net-internals log file for the 3.3 version of the middleware.

Note: in comment 5, you said the error was
net::ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED.  So the error
changed again (back to net::ERR_SSL_PROTOCOL_ERROR) with
the 3.3 version of the middleware.  This is why I think it
may be a different bug.  In any case let's continue the
investigation in this bug report.

Feb 11, 2011
ilya.shmorgun: I updated the test program to investigate the
problem with the 3.3 version of the middleware.

1. Please compile it with the command

cl /EHsc /W3 ClientCert2.cc

and run it with the command

.\ClientCert2.exe

2. If you could also run the Canary build and attach a new
net-internals log file, that'd be great.

Thank you for your help.

Feb 11, 2011
The 3.3 version of the middleware seems to have a bug with
CryptGetProvParam(PP_NAME).

The CryptGetProvParam MSDN page says:
http://msdn.microsoft.com/en-us/library/aa380196(VS.85).aspx

PP_NAME   The name of the CSP in the form of a null-terminated
CHAR string. ...

In https://svn.eesti.ee/projektid/idkaart_public/3.3/esteid-csp/Csp.cpp,
we have:

BOOL Csp::CPGetProvParam(
IN  HCRYPTPROV hProv,
IN  DWORD dwParam,
OUT LPBYTE pbData,
IN OUT LPDWORD pcbDataLen,
IN  DWORD dwFlags){
...
switch (dwParam) {
case PP_NAME :
dat.setValue(m_cspName);break;

In https://svn.eesti.ee/projektid/idkaart_public/3.3/esteid-csp/Csp.h,
m_cspName is defined as a tstring, which is std::wstring if the code
is compiled with -D_UNICODE.

So Csp::CPGetProvParam copies a wide character string into the
result buffer for PP_NAME.  This is the first problem.

The second problem is that the copying function has an off-by-one-byte
bug.  In https://svn.eesti.ee/projektid/idkaart_public/3.3/esteid-csp/CSPTypes.h,
we have:

struct packData {
...
void setValue(tstring a) {
*m_pcbDataLen = (DWORD) (a.length() * sizeof(TCHAR)) + 1;
m_src = (LPBYTE)a.c_str();
copyData();
}

The first line of the setValue() method should read:
*m_pcbDataLen = (DWORD) ((a.length() + 1) * sizeof(TCHAR));

Fixing this off-by-one-byte bug of setValue() is not enough.
Csp::CPGetProvParam still needs to convert m_cspName to std::string
for the PP_NAME case.

I've updated my test program again to use the algorithm described in
http://www.mail-archive.com/xmlsec@aleksey.com/msg02997.html

Please compile it with the command

cl /EHsc /W3 ClientCert3.cc

and run it with the command

.\ClientCert3.exe

Feb 12, 2011
Here is the output from ClientCert3.exe run with middleware 3.3 version.

Provider (W): EstEID Card CSP
Container (W): AUT_3*******
Provider type: 1
Provider: E
Container: AUT_3*******
Provider type: 1
CryptAcquireContextA failed: 0x80090019
Platform auth token is removed

Feb 12, 2011
Here is the net-internals log for the Canary build version 11.0.667.0.

Feb 12, 2011
ilya.shmorgun: thank you very much.  This confirms the bug
in the 3.3 version of the middleware.  Could you submit a
bug report to the maintainer?  You can just use my comment
41.

The "net-interals (11.0.667.0).txt" file shows NSS error
code -12205 (SSL_ERROR_TOKEN_INSERTION_REMOVAL).  Chrome
incorrectly thinks the smard card is removed because the
provider name (PP_NAME) is truncated to just "E".

This bug will be fixed by rsleevi's patch for  issue 71928 ,
which removes the smart card presence test altogether.

rsleevi: in my ClientCert3.cc test program, I made the smart
card test more robust by getting the CERT_KEY_PROV_INFO_PROP_ID
property of the cert.  That property is guaranteed to be
correct (otherwise the client certificate cannot be linked to
the smart card CSP), whereas the PP_NAME property of the provider
is less commonly used.  When we reintroduce the smart card
presence test, we should use this new method.

Feb 12, 2011
The error code 0x80090019 for CryptAcquireContext in comment 42
is NTE_KEYSET_NOT_DEF, "The requested provider does not exist."


Feb 12, 2011
So when will it be possible to test a build with the integrated fix?

Feb 12, 2011
ilya.shmorgun: Try http://build.chromium.org/f/chromium/snapshots/chromium-rel-xp/74717/ . My change landed as 74716.

Feb 12, 2011
I've tested with the snapshot build version 11.0.669.0 (Developer Build 74717) and the authentication appears to be working with middleware version 3.3. I wonder if everything is also working with the older version of the middleware though. Maybe ain.tohvri would be able to confirm that?

Feb 14, 2011
rsleevi: Would you be able to say when the fix might end up in Canary builds for testing?

Feb 14, 2011
ilya.shmorgun: the current Canary build has all the fixes you need.
The version string is:
Google Chrome	11.0.671.0 (Official Build 74789) canary build

Feb 15, 2011
I've tested with Canary build version 11.0.671.0 (Official Build 74789) and the authentication appears to be working.

Feb 16, 2011
(No comment was entered for this change.)

Labels: -ReleaseBlock-Stable
Feb 18, 2011
My request to either merge the fix or revert to the old code on the Chrome
9.0 release branch was rejected.  So this bug will be fixed in the upcoming
Chrome 10.0 release, currently on the Beta channel, and is expected to be
on the Stable channel in early March.

Until then, I recommend that you run the Chrome Canary build as a

Sorry about the inconvenience.

Status: Fixed
Labels: -Mstone-9 Mstone-10
Feb 18, 2011
(No comment was entered for this change.)

Labels: Regression
Mar 8, 2011
I can confirm that authentication is working with version 10.0.648.127 (Official Build 76697) on Windows 7 x64.

Mar 8, 2011
ilya.shmorgun: thank you for verifying the fix.

Chrome 10.0, which has the fix for this bug, has just arrived on the
Stable Channel.  If you are running the Canary build as a workaround,
you can switch back now.

I'd appreciate it if you could continue to run the Canary build to help
us discover regressions sooner.

Status: Verified
Mar 8, 2011
wtc: I have tested this with the stable build of Chrome 10.0.648.127 and everything seems to be working. Also could you please specify, which regressions do you mean?

Mar 8, 2011
ilya.shmorgun: sorry to confuse you.  You can replace "regressions"
with "new bugs".  What I meant to say is:
I'd appreciate it if you could continue to run the Canary build to
help us discover new bugs sooner.

Mar 8, 2011
Wtc: sure and thank you very much for all your effort and hard work!

Mar 18, 2011
(No comment was entered for this change.)

Labels: -Regression bulkmove Type-Regression
Mar 12, 2012
I've tried Canarian version but still don't work. :(
How can I help?
(PT-PT)

Mar 12, 2012
nbranquinho: This bug was marked fixed back in February of last year.

Could you please file a new bug using the new bug template (alternatively available at http://new.crbug.com/ ), so that we can begin investigating?

Please try to include any details about the smart card, the smart card reader, and the smart card software you have available.

Thanks

Jun 21, 2012
Sorry about delay.
I opened a new bug.

Oct 13, 2012
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)