I'm implementing a dtls-srtp handshake from client (openssl with VS C++), but it failed. The message flow on wireshark turned out like this:
Client Hello
Server Hello, Certificate (Fragment), Certificate (Fragment), Certificate (Fragment), Certificate (Reassembled), Certificate Request, Server Hello Done
Certificate (Fragment), Certificate (Fragment), Certificate (Fragment), Certificate (Reassembled), Client Key Exchange, Certificate Verify (Fragment)
Server Hello, Certificate[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]
Client Hello
Server Hello, Certificate[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]
Client Hello, Certificate[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]
Server Hello, Certificate[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]
Certificate Verify (Reassembled), Change Cipher Spec, Certificate[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]
Alert (Level: Fatal, Description: Decrypt Error)
Does anyone has any idea what's going on here? Is it the problem of certificate/key, or did I miss any SSL option / parameter?
I tried to change the mtu value but it didn't work.
Modified: logs from client
*SSL_CB_HANDSHAKE_START unknown: before/connect initialization
SSL_CB_LOOP SSL_connect: before/connect initialization
SSL_CB_LOOP SSL_connect: SSLv3 write client hello A
SSL_CB_EXIT SSL_connect: SSLv3 read server hello A
SSL_CB_EXIT SSL_connect: SSLv3 read server hello A
-> connect err=-1 errRet=SSL_ERROR_WANT_READ
SSL_CB_LOOP SSL_connect: SSLv3 read server hello A
SSL_CB_LOOP SSL_connect: SSLv3 read server certificate A
SSL_CB_LOOP SSL_connect: SSLv3 read server certificate request A
SSL_CB_LOOP SSL_connect: SSLv3 read server done A
SSL_CB_LOOP SSL_connect: SSLv3 write client certificate A
SSL_CB_LOOP SSL_connect: SSLv3 write client key exchange A
SSL_CB_LOOP SSL_connect: SSLv3 write certificate verify A
SSL_CB_EXIT SSL_connect: error
-> connect err=-1 errRet=SSL_ERROR_SYSCALL*
Related
I have an outbound JAX-WS client component to my application. When I run the application locally from my computer it works. When I try running the app in docker it fails with the error in the title of this post.
On my computer the banner in the log file is:
Launching portolano (WebSphere Application Server 16.0.0.3/wlp-1.0.14.cl160320160831-1555) on Java HotSpot(TM) 64-Bit Server VM, version 1.8.0-ea-b121 (en_US)
I am using docker image websphere-liberty:javaee7 and the banner in the log is:
Launching defaultServer (WebSphere Application Server 16.0.0.3/wlp-1.0.14.cl160320160831-1555) on IBM J9 VM, version pxa6480sr3fp20-20161019_02 (SR3 FP20) (en_US)
The problem seems to related to the client handshake.
When I run WebSphere Liberty docker image it uses the IBM JDK and is trying a TLS 1.2 client handshake that is being rejected. Here is the debug when I turn on ssl debugging:
LargeThreadPool-thread-53, WRITE: TLSv1.2 Handshake, length = 201
LargeThreadPool-thread-53, READ: TLSv1 Alert, length = 2
LargeThreadPool-thread-53
, RECV TLSv1.2 ALERT:
fatal,
close_notify
When I run WebSphere Liberty locally on my laptop with the Oracle JDK it tries TLS 1 client handshake that works. Here is the debug when I turn on ssl debugging at the same location in the handshake as above:
Default Executor-thread-23, WRITE: TLSv1 Handshake, length = 183
Default Executor-thread-23, READ: TLSv1 Handshake, length = 65
*** ServerHello, TLSv1
I have no control over the remote server. How can I force the IBM JDK to do the same thing as the Oracle JDK?
TLS 1.0 can forced in the initial handshake by creating a jvm.options file that is provided the the container with the following options:
-Ddeployment.security.TLSv1=true
-Dhttps.protocols=TLSv1
I know there are lots of discussion regarding this error but sorry to say that I'm unable to find any working solution over there.
I'm developing a ecommerce site using ShareTribe.I'm trying to implement Paypal as payment gateway.So I'm using Activemerchant.
Everything works fine on development machine but when I deploy my rails app to production It throws
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)
I'm initializing my Activemerchant as
config.after_initialize do
ActiveMerchant::Billing::Base.mode = :test
paypal_options = {
login: "bla bla",
password: "bla bla",
signature: "bla bla",
appid: "APP-80W284485P519543T"
}
::EXPRESS_GATEWAY = ActiveMerchant::Billing::PaypalExpressGateway.new(paypal_options)
end
Added HTTPS and Disabled SSLV3
After lots of googling I found that
SSLv3 was proven to be insecure with the POODLE vulnerability. You
should make sure that your system has the latest version of OpenSSL so
that you can use TLSv1.2.
So I disabled SSLV3 as shown below
openssl s_client -connect kickmarket.eu:443
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.kickmarket.eu
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...........................................
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.kickmarket.eu
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 2038 bytes and written 375 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 4D23F4A942AAD4264BE96EB5F1E62204269D882A64ACFBD2D139CD2F10A449A0
Session-ID-ctx:
Master-Key: 1E381DAA3BA90FE3609606716E7E9A2EB2E2F671E9F3C4005D8EBAE009103A7AB771FB2AC8B45F169F43CBD0AD352E06
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
..................................
Start Time: 1446132175
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
But after restarting nginx I got the same problem.Is there Any way to fix this issue.
Any suggestion will be appreciated.
This is most likely due to the upgrade to SHA256 certification. Please review the following documentation:
https://devblog.paypal.com/paypal-ssl-certificate-changes/
The primary cause for this is the rvm installed ruby does look into the wrong directory for certificates whereas the OSX-ruby will look into the correct one.
What you wanna do is NOT TO USE any of the precompiled rubies and rather have ruby compiled on your local machine, like so:
rvm install 2.2.0 --disable-binary
You can read detailed explanation https://toadle.me/2015/04/16/fixing-failing-ssl-verification-with-rvm.html
tl;dr
Git on Windows stops connecting to github because of mysterious "SSL protocol" errors. Halp!
The Issue
I'm developing on Windows, using a private GitHub repo for source control. When I first boot my system, I'm able to access the remote repo without issue - pull, push, fetch, etc. all work just fine.
After some amount of time(*), this stops, and I get the following error:
fatal: unable to access 'https://github.com/our-team/private-repo.git/': Unknown SSL protocol error in connection to github.com:443
(*) The amount of time seems variable - I've witnessed as little as an hour or two, up to a whole day. Usually after coming back from the system sleeping, it seems to be an issue, but I don't know if it's caused by a time delay or by the system sleeping.
Checking via cURL, I get
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to github.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to github.com:443
Using set GIT_CURL_VERBOSE=1 with git pull shows similar information. Sometimes it succeeds (see below), but most of the time it fails.
Further Notes
There's a little bit of a sporadic nature to it - sometimes I can get requests to succeed, but once it starts exploding, it's generally broken 9 out of 10 requests or more.
A successful cURL request looks like:
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* TLSv1.0, TLS handshake, Server hello (2):
* TLSv1.0, TLS handshake, CERT (11):
* TLSv1.0, TLS handshake, Server finished (14):
* TLSv1.0, TLS handshake, Client key exchange (16):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* Server certificate:
* subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; street=548 4th Street; postalCode=94107; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: 2014-04-08 00:00:00 GMT
* expire date: 2016-04-12 12:00:00 GMT
* subjectAltName: github.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
* SSL certificate verify ok.
> GET /our-team/private-repo.git/ HTTP/1.1
> User-Agent: curl/7.41.0
> Host: github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Mon, 11 May 2015 15:19:43 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://github.com/our-team/private-repo/
< Vary: Accept-Encoding
< X-Served-By: 76f8aa18dab86a06db6e70a0421dc28c
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host github.com left intact
The Question
I've googled a good bit on trying to find this (over the course of several weeks, so I don't have links), but most suggestions seem to point at certificate errors or OpenSSL version mismatches / bugs (which wouldn't be sporadic like this AFAIK).
What might be causing this failure, and how can I resolve it?
Relevant Software:
λ git --version
git version 1.9.5.msysgit.1
λ curl --version
curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Oddly, it turns out that the issue is that the laptop was throttled because of a weak power supply. The docking station I was using was plugged into a low-amp powersupply (3.3 A), which, while it was compatible with the laptop, immediately kicked it into a heavily-throttled mode.
Apparently, this slowed everything down enough that the SSL handshake wasn't able to complete fast enough.
We finally tracked it down after reading a Dell support forum post (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) that discussed slowness issues. The solution there was to change the power supply.
I had also experienced this slowness, but I did not think it was related. We swapped to a high-amp power supply for the dock, and everything was fine again, and the SSL errors described above went away.
That looks like an error which could result from the security initiatives taken after the Logjam attack -- weakdh.org --.
That resulted in the suppression of some ciphers accepted in a SSL/TLS transaction.
Note that, as reported in "Cannot communicate securely with peer: no common encryption algorithm(s)", you will be able to pass the right cipher list to curl via git.
Before that, you can also try if the issue persists while using a more recent Git for Windows (like the Git 2.4.1)
Had the same issue. Disabled my wifi connection and switched to cable and everything works again. Btw: Used a Dell in Docking-Station too.
I am trying to use cURL and get the following error on every https request I make. The error is always the same. HTTP requests work flawlessly. The verbose output is quite useless.
bash:$ curl https://google.com -vv
* Adding handle: conn: 0x7fe09b803a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fe09b803a00) send_pipe: 1, recv_pipe: 0
* About to connect() to google.com port 443 (#0)
* Trying 74.125.226.129...
* Connected to google.com (74.125.226.129) port 443 (#0)
* Unknown SSL protocol error in connection to google.com:-9805
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to google.com:-9805
bash:$ curl https://google.com -V
curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
bash:$ openssl s_client -connect google.com:443 < /dev/null
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
24255:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s23_lib.c:182:
The results are the same on two different networks, so it does not appear to be network-specific. Attempting to connect using openssl s_client fails similarly so it is not library-dependent either (curl on the Mac uses SecureTransport). The debug output of s_client shows that the SSL handshake proceeds normally to the point where the client sends ChangeCipherSpec and the Finished messages but does not receive ChangeCipherSpec back from the server.
I have tried running these commands on a Debian VM on my Mac, and everything there runs correctly. In addition, using curl to connect to a local OpenSSL server (openssl s_server with a self-signed certificate) also works correctly.
I have looked through other answers on this forum and other places on the internet, but haven't found an answer. Most people's issues involve particular servers and the configuration of SSL on these servers. Mine however is problematic anytime HTTPS is used (with any website).
It was suggested that the issue might be in the certificate store. But if I understand it correctly, if the issue was with the certificate store, it would cause certificates to be rejected by all apps. However, all my browsers (chrome, safari, firefox) negotiate SSL with no problems. There is nothing suspicious in the environment variables for GUI applications or the shell.
Can someone please suggest what I should be looking into to solve the problem? Can it be that something is not properly configured? What should I be looking for?
Everything I try and connect to via https fails. Bellow is a curl output, but it does this with git mongo and everything. darwin just doesn't like https.
About to connect() to github.com port 443 (#0)
Trying 207.97.227.239... connected
Connected to github.com (207.97.227.239) port 443 (#0)
successfully set certificate verify locations:
CAfile: /usr/share/curl/curl-ca-bundle.crt
CApath: none
SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS alert, Server hello (2):
SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
You might say not a problem just change https to http, yes this is fine when you only have
1 url like git clone but on rvm install about 50 of the required things fails to install because of this. I don't want to go into rvm and change all occurrences of https to http.
Take a look at this post, slightly different, but i think it will answer you questions:
SSL certificate rejected trying to access GitHub over HTTPS behind firewall
You can essentially have OSX ignore the SSL Cert Verify, and accept the connection.
It turned out that my version of curl was using an old certificate to validate https.
I cam across this issue on git for cURL under Leopard:
https://github.com/mxcl/homebrew/issues/11947
And the error went away and I am now able to download https files from cURL.
This looks like an issue with curl itself, rather than OSX. What version are you using? If it's particularly old, then the reference here to a "severely outdated CA file" probably applies.
Try installing up-to-date versions of curl and git from macports.