This sounds familiar to what we reported a while back:
http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html
<http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html>
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 <s...@stfx.eu> wrote:
>
>
>> On 27 Feb 2015, at 21:18, Sabine Manaa <manaa.sab...@gmail.com> 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.
>
>
