This question already has answers here:
Why do browser implementations of HTTP/2 require TLS?
(1 answer)
How to implement http2 without ssl in Apache 2.4.18 Server
(1 answer)
Tomcat 8.5 - Is Certificate/SSL required for HTTP2
(1 answer)
Why do web browsers not support h2c (HTTP/2 without TLS)?
(1 answer)
HTTP/2 behaviors with HTTP and HTTPS
(2 answers)
Closed 2 years ago.
According to the HTTP/2 spec (rfc7540), implementations of HTTP/2 require TLS version 1.2 or higher.
Implementations of HTTP/2 MUST use TLS version 1.2 [TLS12] or higher
for HTTP/2 over TLS
However, in the HTTP2 FAQ documentation, HTTP/2 does not require encryption(e.g., TLS).
No. After extensive discussion, the Working Group did not have
consensus to require the use of encryption (e.g., TLS) for the new
protocol.
I am little bit confused. Can you explain it to me to understand it more?
Related
gRPC is based on http2 which must be use ssl.
But I found I can create use insecure server.
I want to know insecure means that don't use ssl or use predefined certificate for http2?
HTTP/2 does not insist on SSL/TLS. But all web browsers only implement HTTP2 over SSL/TLS because of problems when using it over plaintext HTTP over the Internet. So if not using a web browser but another HTTP/2 client than you can use HTTP/2 without SSL/TLS.
So yes insecure gRPC is using an unencrypted HTTP/2 connection (h2c). Though some implementations do not support this, similar to how web browsers do not support unencrypted HTTP/2 (h2c).
I just received an email from Authorize.net informing that they deactivate connections to their server using TLS1.0 and TLS1.1.
Question are Godaddy SSL and Web Host set for TLS1.2 connections and is there anything need to change for configure TLS1.2 for my site?
How to check which TLS use in my website?
How to check which TLS use in my website?
Use Qualys SSL Labs vulnerability tester to check which TLS version you are using: https://www.ssllabs.com/ssltest/
You may certainly see that you support several versions (this is the most common case).
Question are Godaddy SSL and Web Host set for TLS1.2 connections and is there anything need to change for configure TLS1.2 for my site?
You have nothing to do, web hosting services by GoDaddy are already supporting TLS 1.2 connections (and TLS 1.0 and TLS 1.1 - they do not support SSL v3 nor SSL v2 anymore, and it's a good thing).
What are the major differences between HTTPS 1.x vs HTTPS 2.x?
Is the TLS and SSL part came in version 2.x?
Is HTTP/2 (https://en.wikipedia.org/wiki/HTTP/2) also called HTTPS 2? Is HTTP 1.1 ( https://www.rfc-editor.org/rfc/rfc2068 ) also called HTTPS 1?
There is no HTTPS 1.x or HTTPS 2.x. There are only HTTP 1.0, HTTP 1.1 and HTTP/2. HTTPS means only that any of these HTTP protocols are encapsulated inside a TLS connection.
The TLS part is basically the same for all of these. But there are some restrictions regarding the protocol versions, ciphers and TLS compression when using TLS with HTTP/2, see RFC 7540, section 9.2 for the details. And to make it easier for the server to know the major HTTP protocol version used inside this TLS connection the client should use the ALPN TLS extension to tell the server that it supports HTTP/2.
I'm updating an embedded TLS 1.0 implementation to TLS 1.2 (devices with 1MB of code space or less, and no OS). At this point, I have AES-128 and AES-256 CBC ciphers working with SHA-1 and SHA-256 digests for a minimal implementation. The library cannot negotiate an SSLv2, SSLv3, TLS 1.0 or TLS 1.1 connection.
I felt this would be sufficient, given that RFC 5246 states, "TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite."
Yet as I read various postings on security blogs, I'm seeing recommendations that would have users disable that suite, and (for example) only allow the ECDHE_RSA or DHE_RSA variants.
So my question is whether devices using our library will interoperate with modern web browsers (as a server) and modern https/smtps/pop servers (as a client). Are there TLS 1.2 clients/servers that fail to negotiate a TLS_RSA_WITH_AES_128_CBC_SHA connection?
I am not sure there are currently many servers supporting TLS that would fail negotiating TLS_RSA_WITH_AES_128_CBC_SHA with TLSv1.2 as it is THE mandatory cipher suite for TLSv1.2.
However there are things to keep in mind:
TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory for TLSv1.0 and TLSv1.1 but due to security reasons it is no longer supported by every server,
Mozilla recommends (and it is not the only one) to favor AES128 instead of AES256,
Perfect Forward Secrecy (PFS), allowed by DHE or ECDHE is now a must-have feature.
So if I can provide you with 4 cipher suites (the same number than you have), I would say these ones from the strongest to the weakest:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
I would say that these 4 cipher suites bring enough security and compatibility with TLSv1.2 servers.
Now the question of supporting only TLSv1.2 is another question, but if you have enough space, I recommend you to add TLSv1.0 too (TLSv1.1 does not provide extra compatibility).
PS: The reason why AES128 is favored instead of AES256 is that some people think the extra security added by AES256 is (for now) worthless and that AES128 seems to be more resistant to timing attacks.
"So my question is whether devices using our library will interoperate with modern web browsers (as a server) and modern https/smtps/pop servers (as a client). Are there TLS 1.2 clients/servers that fail to negotiate a TLS_RSA_WITH_AES_128_CBC_SHA connection?"
Yes there are plenty implementations that fail.
Most common:
Clients that still send a SSL2.0 Client Hello
Clients/Servers that only support PFS cipher suite
Servers that still not support TLS 1.2
Servers that no longer support TLS 1.2 - since those only support TLS 1.3
My recommendation is:
also support TLS 1.3 (not that hard to implement, I did it)
also support DHE
Or use a tool/site like https://www.ssllabs.com/ssltest/index.html and test the compatibility/security of your server until it's sufficient for you.
Following a really outdated tutorial I managed to create an HTTPS server using OpenSSL with TLS1.2, and I'm very proud of it ;)
However TLS 1.2 is only supported in latest browsers and I would like to have some kind of negotiation of the protocol between the client and server, which I'm sure it can be done, but I'm not able to find how! So that if the client only supports TLS1.0, well use that. And if it only supports SSLv3, use that. Not sure about SSLv2, maybe better leave that...
The code I use right now is:
SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ssl_method = TLSv1_2_server_method();
ssl_ctx = SSL_CTX_new(ssl_method);
Then the server certificates are loaded and the ssl_ctx is shared among all connections. When a client is accepted by the server socket it is encapsulated in an SSL object (whatever it represents):
ssl = SSL_new(ssl_ctx);
SSL_set_fd(ssl, client_socket);
SSL_accept(ssl);
So I guess that something has to be changed in the ssl_ctx creation to allow more methods... Any idea?
<rant> No decent, extensive documentation can be found for OpenSSL, the best available is a 10 years old tutorial! </rant>
Thanks in advance.
You do this by using SSLv23_method() (and friends) instead of a specific method (e.g. TLSv1_2_server_method() in your example). This sends the SSLv2 ClientHello but also specifies the highest protocol supported. The somewhat outdated man page says:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand
the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
client hello messages and will indicate that it also understands SSLv3
and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client
hello messages. This is the best choice when compatibility is a
concern.
This online man page doesn't discuss the newer TLSv1_1 and TLSv1_2 protocols, but I verified in the 1.0.1g source of s23_clnt.c that SSLv23_method() includes them.
You then limit the protocols you actually accept with SSL_CTX_set_options():
The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.
Note, however, that you can't enable arbitrary sets of protocols, only contiguous protocols in SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2. For example, you can't choose only SSLv3 and TLSv1_1, omitting TLSv1. This comment in the source explains why:
SSL_OP_NO_X disables all protocols above X if there are some protocols below X enabled. This is required in order to maintain "version capability" vector contiguous. So that if application wants to disable TLS1.0 in favour of TLS1>=1, it would be insufficient to pass SSL_NO_TLSv1, the answer is SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2.