Since a few days I can't send text messages from my application made with vb.net. When debugging I get this error
Twilio says Invalid TLS protocol
Did you take a look at the documentation here?
Tips for Upgrading Your Environment to Support Twilio REST API’s TLS and Strong Cipher Suite Changes
Related
Before starting this project, I have never directly worked with API requests. I have learned a lot and I am able to successfully get valid responses from the FedEx and USPS tracking APIs. However, I am unable to get anything besides a 403 Forbidden error when trying to get a response from UPS.
I have been in contact with their tech support and they verified I am using the correct endpoints and credentials, so they said it must be a security issue. I needed an up to date certificate and they gave me a list of supported security ciphers.
TLS 1.2
1. ECDHE-RSA-AES256-GCM-SHA384
2. ECDHE-RSA-AES128-GCM-SHA256
3. ECDHE-RSA-AES256-CBC-SHA384
4. ECDHE-RSA-AES256-CBC-SHA
TLS 1.3
1. TLS_AES_256_GCM_SHA384
2. TLS_CHACHA20_POLY1305_SHA256
3. TLS_AES_128_GCM_SHA256
4. TLS_AES_128_CCM_8_SHA256
5. TLS_AES_128_CCM_SHA256
I followed a guide online to create and sign a server certificate for my localhost. However, I have no idea what to do with the ciphers. When I check the security tab in DevTools, I can see that the cipher used for localhost is AES_256_GCM Protcol TLS 1.3 with Key exchange group X25519.
Is there any way I can configure my XAMPP Apache server to have these ciphers only?
UPS Tech support said I should check with my company's IT team or Network Admin but we don't really have one besides me. Any help would be appreciated and I would be happy to share my code for the API call.
I'm writing protocol that encrypts whatever is being sent using TLS. For TLS, I'm using schannel on Windows.
For testing, I'm connecting to IIS, doing GET, and connecting using Chrome to my server, just sending back HTTP 200 response.
However, there are few edge cases I'm unable to check with this. I want to use someone else's implementation for reference, so I don't end up with bogus implementation on both sides.
Is there any testing TLS server (client), which can I use for testing
renegotiation
partially sent message
extra data in handshake / message (DecryptMessage to have filled SECBUFFER_EXTRA buffer)
?
Thanks.
Using simple podio api things, but overnight I have this message:
Fatal error: Uncaught exception 'PodioConnectionError' with message
'Connection to Podio API failed: [35] Unknown SSL protocol error in
connection to api.podio.com:443
No SSL have changed from my part, and as long as I know, podio api is the same since 2015...
Thanks!
No SSL have changed from my part, and as long as I know, podio api is the same since 2015...
It is very likely that you are using some old TLS stack with no support for TLS 1.2 or that you've explicitly setup your system to use TLS 1.0 only. From Podio Help Centre:
API Security Update
Upcoming change for developers using Podio's API ....What you need to do by 27 June 2018
Ensure you are using TLS 1.1 as a minimum, though we recommend upgrading to TLS 1.2. This applies to private, public and partner applications connecting to the Podio API.
Podio have disabled TLS 1.0 - the last bit was done yesterday.
TLS 1.0 was deprecated a while ago, and it's end of life was set to June 2018.
Details are here: https://help.podio.com/hc/en-us/community/posts/360003048772-API-Security-Update
Podio will also disable TLS 1.1 some day, so if you are upgrading - move to latest TLS 1.2.
I am getting the following error while trying to connect PayPal with transaction details using an API:
Type PPConnectionException
Message error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Detail Error connecting to https://api-3t.sandbox.paypal.com/2.0
Why does this error occur?
Take a look at this article about the POODLE Vulnerability.
That post is specific to PHP environments, but the basic problem is that your server software stack needs to be able to send the POST requests to PayPal over the TLS 1.2 protocol instead of SSL.
As far as I understand, https is http plus SSL/TLS.
What do I need to do if I want to add 3 more parameters for the header?
I found a file inside Mozilla's NSS - ssl3ext.c, but I don't understand it and don't know how to start. Need a clue from you guys..
Is this something about SSL/TLS extension? But it is far more complex right?
SSL/TLS is a transport layer. It's negotiated first, and then HTTP talks "over" it. To add more HTTP header parameters you do exactly the same as you would normally.
(to be completely clear - HTTPS is HTTP "on top" of TLS/SSL. The TLS/SSL connection is made first and then HTTP uses it just like it would use an unencrypted transport).
if a developer would like to add some
more information/parameters for his
SSL communication/handshaking, where
does the parameter should be located?
RFC 3546 'Transport Layer Security (TLS) Extensions' is the only defined way to add additional parameters to the SSL/TLS handshake.
You can add your extension to the Client Hello message. If the server recognizes it, it can respond with a corresponding extension on the Server Hello message. The server cannot send it unless it was requested, however.
is it inside the code for http header
or is it creating a new extension for
TLS like the server name
indication(SNI)?
It has nothing to do with HTTP. The SSL/TLS handshake is over before HTTP even begins.
I have looked into the code and RFC
for SNI but seems does not get any
clues?
Look at RFC 3546 for the extension format. The IANA manages the extension numbers.
http://www.iana.org/assignments/tls-extensiontype-values/
Note that there is no 'experimental' range for you to use. IMHO what you do over your own ports is your own business, but be aware of the possibility of conflict in the future.
Does adding more parameters to the
handshaking process will disturb the
current implementation?
Some SSLv3 and older TLS 1.0 servers will hang up on you if you send an extension they don't like. Major web browsers implement fallback reconnect logic without extensions.
will it broke the standard?
If your extension follows the general format for extensions defined in RFC 3546, the only (modern) standard you are breaking is that you are not using an IANA-blessed extension ID number. If your extension is generally useful, you should strongly consider submitting it for formal standardization.
You can add as many HTTP header parameters as you like, without concern for SSL. If you want to modify the SSL handshake, you should have the source to your SSL libraries on both sides of the connection.
I'm not sure what your trying to do here though. You could modify the ClientHandshake to include more/customer cipher suites. You could also define a custom content type. Currently the first byte in a TLS record determines the content type, which are as follows:
0x14 20 ChangeCipherSpec
0x15 21 Alert
0x16 22 Handshake
0x17 23 Application
Depending on what you are trying to do, you may be well served by adding a custom alert to the Alert Protocol. Alerts can be sent at any time, in either direction.
Customizing the protocol will break the standard, though you can do things like add cipher suites without changing the protocol. Between client certs and server certs, the protocol generally has everything most people need for authentication and encryption.