I am relating to Application and invalid certificate errors
When i initiate the call with Twilio REST API, and then pick up the phone, i can hear that error occured and Certificate Invalid - Could not find path to certificate appears in my alert dashboard.
However, certificate is located in the mozila certificate program, i can find certificate at Public All Intermediate Certs List. I dont use self signed certificate.
As soon as i disable SSL Certificate Validation inside Twilio Console Account settings, the problem is gone.
My result from qualys ssl lab are:
Summary:
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
This server accepts RC4 cipher, but only with older protocols. Grade capped to B.
The server does not support Forward Secrecy with the reference browsers.
This server's certificate chain is incomplete. Grade capped to B.
Configuration:
SSL 3 INSECURE
Cipher Suites:
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 4096 bits FS WEAK
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE
Protocol details:
Secure Renegotiation Supported
POODLE (SSLv3) Vulnerable INSECURE SSL 3: 0xa
Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported
RC4 Yes INSECURE
Forward Secrecy With some browsers
Shall i disable SSL or do you have any ideas what can i do?
Twilio developer evangelist here.
I am hoping that your https://ssllabs.com/ssltest has scared you sufficiently enough. You need to upgrade your server from SSLv3 to TLS as SSLv3 and a lot more of your setup is insecure and will not protect you in the face of an attack.
Twilio has deprecated support for SSLv3 and supports TLS. This is likely why you are getting an invalid certificate error.
For the sake of your and your users own security and safety, please upgrade your server.
Related
I am fairly new to Pound cfg and SSL in general and working on learning. Tried a few things I found on Google related to setting Ciphers but they failed.
We are having an issue with Firefox after setting Ciphers in Pound to not allow SSLv3. Firefox tells customers that the system is not setup properly, so it is blocking them. Here is what I am trying to do.
Disallow SSLv3, SSLv2 via Pound Cfg file. Here is what I have tried:
Ciphers "All:!SSLv2:!SSLv3"
We are using SHA2 through Godaddy for Cert and SHA256 for key. When I test via https://dev.ssllabs.com/ssltest/ we get a giant F. Any ideas?
Any and all help is greatly appreciated. Thanks!
"Ciphers" is used to configure the cipher suites, not the SSL/TLS protocols. According to the man page, you want to do this:
Disable SSLv3
Note that Disable works by disabling that protocol and all lesser protocols, so disabling SSLv3 also disables SSLv2 along with it.
You will probably want to configure Ciphers as well. Exactly how you configure it depends on what browsers and user agents you want to support, but you can get started with:
Ciphers: "EECDH+AESGCM:AES128+EECDH"
I have been a long time reader but this is my first real post on a topic that I couldn't find a solution to.
I am currently hosting a website on Windows 2012 that I would like to get the latest TLS 1.2 ciphersuites running on.
I am aware of how to enable TLS 1.1 and TLS 1.2 in windows and have done so(via registry edits). I have also changed the cipher order to what I would like it to be.
My question is: How do i actually go through and set up my ECDHE / ECDSA portion of the cipher suite after this step?
When i view the site in the latest chrome beta (which supports ECDHE and ECDSA in TLS 1.2 provided you use the supported curves) it seems to skip all of the ECHDE ciphersuites.
Is there something else i need to do to get ECDHE/ECDSA properly enabled?
I have read around on the net trying to solve this myself and they mention making copies of your root cert and then modifying them to somehow support ECDHE. Am i barking up the wrong tree?
Thank you in advance for any and all support with this issue.
Edit: adding clarification/progress
After more research, I have found that in order to get ECDSA to work, you need an ECDSA certificate. The only way to get one at this time is to self-sign, as the cert-cartel has not yet come up with proper cross-licensing agreements and fee structures for Ellipic Curve Certificates yet.
Since self-signing is not an option for this site, I have removed all ECDSA suites from the cipher-order.
Unfortunately, because all of the AES Galois Counter Mode suites were also ECDSA, this rules those out for the time being.
This leaves me with a strongest cipher suite of ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 which I BELIEVE is supported by the latest version of Chrome beta correct? I can't seem to get Chrome to pick up anything beyond SHA-1. Is there no SHA-2 support? even in the latest beta?
AES-GCM is about how you encrypt the data in your connexion, EC-DSA or RSA about how the server identifies itself to the client. There is therefore no reason why you couldn't do AES-GCM encryption with a RSA authentication.
RFC 5289 does define the needed suite for that :
https://www.rfc-editor.org/rfc/rfc5289#section-3.2
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2F};
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30};
CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x31};
CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x32};
It's not however necessarily easy to find both the client and the server that will support them.
I had similar experiences with Win2008 R2.
Depending on the certificate, GCM cipher is offered by the server or not.
With self-signed ECDSA certificate i got GCM to work but older browsers
or Windows XP can't connect to such a https-site.
Windows doesnt support any TLS_ECDHE_RSA...GCM... ciphers:
http://msdn.microsoft.com/en-us/library/aa374757(v=vs.85).aspx
Thus normal RSA-certificates don't work with GCM under Windows.
Browser compatibility:
http://www.g-sec.lu/sslharden/SSL_comp_report2011.pdf
I am writing a soap request over SSL using Savon and HTTPi, a Ruby soap client and an interface for Ruby HTTP clients, respectively. Here's the code:
client = Savon::Client.new(original_class.constantize.wsdl_url)
client.http.auth.ssl.cert_key_file = "path_to_the_key"
client.http.auth.ssl.cert_key_password = 'secret'
client.http.auth.ssl.cert_file = "path_to_the_certification"
client.http.auth.ssl.verify_mode = :none
#response = client.request :ins0, action do
soap.body = encoded_body
end
That's the only way I get this to work. But, I know that there is three others verify modes, which are:
:peer (SSL_VERIFY_PEER)
:fail_if_no_peer_cert (SSL_VERIFY_FAIL_IF_NO_PEER_CERT)
:client_once (SSL_VERIFY_CLIENT_ONCE)
If I change the verify mode to any other of the above, I get this error:
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
Then comes my questions (among others I have):
Am I doing wrong if I keep the verify mode to :none? Is there any lack of security?
What does the error really mean? That my code is wrong or that my certificate (which is self-assigned --- I am in development environment) is not good?
I read the OpenSSL documentation about verify modes:
http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html
About SSL_VERIFY_NONE, on Client Mode, says:
The result of the certificate verification process can be checked
after the TLS/SSL handshake using the SSL_get_verify_result(3)
function. The handshake will be continued regardless of the
verification result.
Should I be worried about it? Should I see verify mode :none as a dangerous thing?
I am asking that because since I can't make it work with the others verify modes, I would like to release the soap request over SSL feature the way it is working now. But I surely wouldn't do it if that could be dangerous.
It is NOT safe to set verify mode to :none (SSL_VERIFY_NONE). This opens up the code to being susceptible to man-in-the-middle attacks. With :none, there will be not server authentication. If an attacker intercepts the connection from my client, my client will not detect the difference and will give any sensitive data communicated through this socket to the attacker.
The mode flags :fail_if_not_peer_cert and :client_once are only for a server; meaning nothing to the client, it ignores them.
For client purpose, :peer (SSL_VERIFY_PEER) is the only one the matters. In order to use :peer, I need to have the root certificate used by the certificate in the client trustedstore.
A big thanks to Dave Thompson from OpenSSL User Support Mailing List. After I joined this list, I finally got help.
My Server is configured to accept both SSLv3 and TLS1.0 protocols. But a few clients are sending below handshake parameters and after the server hello, the client drops the connection and sends 'handshare failure(40) alert, not sure if it's the client fault or server.
Here's the initial client hello packet:
Secure Socket Layer
SSLv3 Record Layer: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300) <-----------------
Length: 103
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 78
Version: TLS 1.0 (0x0301) <-------------
Random
Session ID Length: 0
Cipher Suites Length: 18
Cipher Suites (9 suites)
The Record layer is SSL 3.0 but the inside handshake protocol is TLS 1.0. My question is, is this the right way of doing it i.e. using different versions for each layer? if it is what method is it? I can't find it anywhere, I looked through the RFC but can't find any reference. Also, how can I produce such requests?
EDIT: I'm not interested in troubleshooting and fixing the issue, I just want to know how can I send such packets? Any command? And what should I name this method?
i.e. I can use curl or openssl to either use ssl3 or tls1 but that would send same version in both record layer and handshake layer:
curl -v -ssl3 https://www.mywebserver.com
Above curl command would look on wireshark:
EDIT2: Is this even legal? I have been googling around and can't find any example. Is it violating any rfc standards?
Thanks
Yes, this is legal (at least it was clarified in recent TLS specifications).
You can look this up in rfc5246 (TLS 1.2) or in rfc6101 (SSL 3.0) or other rfc's concerning the SSL/TLS. The problem is with the initial version of the record protocol and with the handshake protocol:
rfc5246:
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version.
Regarding the handshake protocol, the client will negotiate the highest version that it has implemented:
client_version: The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client
I just want to know how can I send such packets? Any command?
openssl s_client -connect www.myserver.com:443 -no_ssl2
should produce something similar to the trace you provided.
I'm going crazy with Apple push notification!
I've developed my app and test notifications following Ray Wanderlich tutorial and everything worked fine until I changed the file .pem with the distribution one and changed the connection string from gateway.sandbox.push-apple.com to gateway.push-apple.com.
Now if I try to send a message the server returns
Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://gateway.push.apple.com:2195 (Connection timed out)
Failed to connect: 110 Connection timed out
The php file and the .pem file are on a TMDHosting: I try to ask them if port number 2195 is closed because googling I found that the error means port is closed.
Though, I can't understand if the error is linked to the certificate or to the server.
The strange things is that if I follow the procedure with the Terminal to test the .pem file , everything seems to work
CONNECTED(00000003)
depth=1 /C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Cupertino/O=Apple Inc/OU=Internet Services/CN=gateway.push.apple.com
i:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
1 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEXTCC..........
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc/OU=Internet Services/CN=gateway.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
No client certificate CA names sent
---
SSL handshake has read 2541 bytes and written 2039 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: CBA98981BB512ED2FDF0C003F4556FDDA564BEBBEFC6528C37D8E0336BC141AEC6D7E014568B334B8330FFFE266E8CB4
Key-Arg : None
Start Time: 1332945845
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
This lets me to think that it's not a .pem problem...
Am I wrong?
I've already read all the similar question here, and tried to change the port number from 2195 to 30, but nothing changes.
Hints?
EDIT: I found that and seems equal to my problem: TMDHosting told me
...you are located under a shared hosting environment and opening a
port for you will be not possible. However note that the address to
which you are making a connection on port 2195 is not associate with
our server. In other words you are trying to make a connection to a
remote server on port 2195. In order to make this connection to the
port specified above you should make sure that the port is opened for
incoming connections on the remote server and not on the server on
which your account with us relies.
Do I need a VPS?
EDIT2:
In the tutorial I followed I found
.. you will need a server that is connected to the internet. Push
notifications are always sent by a server. For development you can use
your Mac as the server (which we’ll do in this tutorial) but for
production use, you need at least something like a VPS (Virtual
Private Server). A cheap shared hosting account is not good enough.
You need to be able to run a background process on the server, install
an SSL certificate, and be able to make outgoing TLS connections on
certain ports. Most shared hosting providers do not let you do this,
although they might if you ask. However, I really recommend using a
VPS host such as Linode.
At last I think I do need a VPS. Can you confirm for sure?
But why if I send push notification with the sandbox server it works properly without VPS?
LAST UPDATE: (hope to help someone) it seems like there was a bug because the right thing is that I cannot send push notification not to the sandbox nor to the production server from my hosting (TMDHosting): my shared hosting has not the 2195 port open. Changed provider: everything works.
Miwi,
Thanks for this detailed writeup.
We are having a similar issue and it is driving us nuts.
When we test the cert, it appears to work, other than:
"verify error:num=20:unable to get local issuer certificate"
Regardless, we get a valid handshake with the command line test of openssl, just as you do.
We can get the sandbox/dev cert to work as well.
Can you let us know what provider you switched to just in case we need to make the switch?
Thanks.