I have a business requirement to use TLS 1.1 or greater and to not use SHA-1 (or RC4).
Are there any known-secure implementations of TLS 1.1 that do not use SHA-1 for the MAC? I can't seem to find any. I am thinking I should just skip past TLS 1.1 at the moment if there are no secure MACs available.
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 studying for this exam identity & access management. The question is what is the difference between one way authentication and mutual authentication? Our prof says mutual is TLS but if I search on the internet TLS is also one way authentication... So I'm a bit confused
I have implemented both one-way and mutual SSL in Applications hosted on Java and Webmethods technology. In One-way authentication, there is a server certificate that the client receives, trusts it (registers it) and sends back a secret along with the server certificate. Hence, a successful SSL Handshake occurs.
In mutual SSL, in addition to trusting the Server Certificate, the Client also provides it's own certificate to the Server. Hence, a mutual trust is maintained between the Server and the Client after which the secrets are transferred.
TLS is a protocol for guaranteeing security in the exchange of information. It is used in particular on the HTTP protocol. The TLS protocol allows both unilateral authentication and bilateral authentication (or mutual authentication). Recently I published on GitHub a project that implements a system of Mutual Authentication based on Apache 2.4 and the TLS 1.2 protocol. https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/
The attached image shows the call to a REST service in mutual authentication
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 have a challenging question. How can I define new ciphersuites such as an encryption scheme A with AES256 (Hybrid) in combination with a Signature scheme B in order to operate it with Bouncycastle TLS 1.3 or TLS 1.2.
I do not want to use predefined ones from bouncycastle.
What are the steps towards doing this? Is there a fast way?
The same also for JCE?
Many thanks for your great help.
Is it possible to have a cut down implementation of TLS , where we just
presume the server we are connecting to is trusted - after the server sends its
certificate, can we bypass verification of this and do away with any further
processing , and get right into standard http ? Is using public key encryption
something that is absolutely necessary , or can it be skipped ?
Rewording my question.
Is it possible to write a tls engine by skipping the need to use RSA public key
code ?,
or
Can a client notify the server during the handshake that it just requires the severs certificate
info, company name, expiry dates and requests the secret cipher key to be sent in plain text.
Skipping something in a protocol I don't fully understand is generally a bad idea.
Only steps marked as optional in the RFC can be safely skipped.
Therefore if you don't plan to use client-side certificate based authentication you can skip it.
However what you can do however is limit the number of variations in your implementation. This means support only one TLS version (e.g. TLS 1.2) and support only one dedicated cipher suite.
Anyway the pitfalls when implementing TLS are so numerous that I recommend you to use an existing implementation (e.g. implementing in a way that does not allow side channel attacks is not that simple and requires knowledge on that topic). There are other implementations beside OpenSSL with a much smaller footprint.
BTW: If you can presume the connection is trusted you don't need TLS. If you need TLS it should be a secure.
where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing
The point of verification is less to find out if the server is trusted, but more that you are actually talking to the server you expect to. If you omit this step you are open to man-in-the-middle attacks.
But, TLS is a very flexible protocol and there are actually ways to use anonymous authentication or a shared secret with TLS and thus skip usage of certificates. Of course in this case you would need to have some other way to validate the server, because otherwise you would be still open to man-in-the-middle-attacks. And because this use case is mostly not relevant for the common usage on the internet it is usually not implemented inside the browsers.