Smalltalk › Pharo › Pharo Smalltalk Users
Login  Register

Re: Zinc SSL Exception: decrypt failed code:5

Posted by Johan Brichau-2 on Feb 28, 2015; 10:01am
URL: https://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808512.html

Hi Sabine,

I took a closer look and indeed, that strategy probably only works in our usecase where it’s a download of a zip tarball from github that fails in the Metacello code.
Because on the second try, the github cache was already created, Metacello no longer sends the request to github and we pass by it.

So, our ‘workaround’ does not apply outside of downloading from github. 

It does seem to be the same problem though. The SSL plugin is reporting an error while the connection closed just fine.
If that’s the case, the culprit is the SSL plugin… 

Johan

On 28 Feb 2015, at 10:44, Sabine Manaa <[hidden email]> wrote:

Hi Johan,

I tried this: I put an exception handler around and on error, I tried again, but the error still occurs.

Regards
Sabine

2015-02-28 8:54 GMT+01:00 Johan Brichau-2 [via Smalltalk] <<a href="x-msg://97/user/SendEmail.jtp?type=node&amp;node=4808511&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]>:
This sounds familiar to what we reported a while back: 

Unfortunately, we did not investigate any further. Instead, we work around the bug by just retrying the connection on this failure as it always works on a second try.

Johan

On 27 Feb 2015, at 23:36, Sven Van Caekenberghe <[hidden email]> wrote:


On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email]> wrote:

Hi Sven,

thank you for your hints.

Indeed, the variable @in of ZdcSecureSocketStream has the string  "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 variable.

That is normal: the in buffer contains encrypted binary data, the out buffer will contain the cleartext (but still in binary).

Can you tell me, what to add to the pharo code that the encoding is correct/so that is equal to the curl command?

I don't think there is an encoding problem: the charset is set to utf-8 which will be picked up. Besides, the returned content is plain ascii anyway.

The issue is probably the Connection:close and the missing Content-Length. This means that the HTTPS stream has to be read until the end. I have seen this fail in the past in rare cases.

Are you on Windows ?

Could you try on Linux ?

comparison of headers: they seem to be equal, also the content type is in both cases 'application/json;charset=UTF-8'
The ZnResponse headers:
a ZnHeaders(
same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 'no-store')
same 'Connection'->'close' 
same 'Content-Type'->'application/json;charset=UTF-8' 
same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT' 
same 'Expires'->'0' 
same 'Pragma'->#('no-cache' 'no-cache') 
same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net; path=/' 
same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains' 
same 'X-Application-Context'->'0.3:8080' 
same 'X-Content-Type-Options'->'nosniff' 
same 'X-Frame-Options'->'DENY' 
same 'X-Xss-Protection'->'1; mode=block' )

result of curl command at command line
< HTTP/1.1 200 OK
same < Date: Fri, 27 Feb 2015 17:58:37 GMT
same < X-Content-Type-Options: nosniff
same < X-XSS-Protection: 1; mode=block
same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
same < Pragma: no-cache
same < Expires: 0
same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains
same < X-Frame-Options: DENY
same < X-Application-Context: 0.3:8080
< Cache-Control: no-store
< Pragma: no-cache
same < Content-Type: application/json;charset=UTF-8
same < Connection: close
same < Set-Cookie: crbid=10.1.8.5:49387_mt05.prod.gini.net; path=/

regards 
sabine

2015-02-27 16:58 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>:
Sabine, 

On 27 Feb 2015, at 16:36, Sabine Manaa <[hidden email]> wrote: 

Hi Sven, 
Hi all, 

I try to send a curl command (which works at command line) from Pharo. 
I get the error: "SSL Exception: decrypt failed code:5" 

The working command line command is: 

curl -v  -H 'Accept: application/json' -u 'aUser:aPassword' 
'https://user.xxx.net/oauth/token?grant_type=client_credentials'

the result is something like: 
{"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"} 

My current Pharo code is: 
      | theZnClient | 
      theZnClient := ZnClient new 
              systemPolicy ; 
              https; 
              host: 'user.xxx.net'; 
              path: 'oauth/token?grant_type=client_credentials'; 
              username: 'aUser' password: 'aPassword'; 
              accept: ZnMimeType applicationJson; 
              get. 
      theZnClient inspect close. 

'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons. 

In Pharo, I get a walkback with the error message 
'SSL Exception: decrypt failed [code:-5]' 

But I see, that the ZdcSecureSocketStream has the correct result 
({"access_token":...":"write"}) in its collection attribute at 
utf-8 string and at latin1-string 

so, the request is done and the result is available but then it fails here: 
ZdcSecureSocketStream(Object)>>error: 
ZdcSecureSocketStream>>sslException:code: 
ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... 
ZdcSecureSocketStream>>fillBytes:startingAt:count: 
ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait 
ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer 
ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: 
ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: 
ZnUTF8Encoder>>readInto:startingAt:count:fromStream: 

Sven, I could send you the 'aPassword' and 'aUser' and the url by private 
message. It would be fine if you could have a short look at it. 
The fact that there is readable text in the buffer of the ZdcSecureSocketStream is good, because it means that things basically work. 

One reason why this is failing might be that Zn tries to read more than there is available in the stream, when the content-length does not match. Encoding problems could be part of the problem too. 

Could you compare curl -v or curl -D - output with the request/response headers in Pharo ? Look for content-length and compare that with what it already read or not. Is the connection kept alive ? Also look at content-type and see if there is any charset encoding after application/json. 

Sven 

Regards 
Sabine 



-- 
View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808345.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. 





If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808353.html
To start a new topic under Pharo Smalltalk Users, email [hidden email] 
To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here.
NAML


View this message in context: Re: Zinc SSL Exception: decrypt failed code:5
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.





If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808485.html
To start a new topic under Pharo Smalltalk Users, email <a href="x-msg://97/user/SendEmail.jtp?type=node&amp;node=4808511&amp;i=1" target="_top" rel="nofollow" link="external" class="">[hidden email] 
To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here.
NAML


View this message in context: Re: Zinc SSL Exception: decrypt failed code:5
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Free forum by Nabble Edit this page