In TLS it is possible to negotiate a next-protocol using ALPN, originally created to deal with HTTP/2. It would be nice to be able to register multiple listeners for different next-protocols. How do I do that in twisted? Is there a twist command line syntax for this?
There isn't a generic ALPN dispatcher. twisted/web/http.py chooses protocols based on NPN/ALPN here and the documentation has an example of using ALPN.
Related
I'm having trouble blocking the use of HTTP/2 in order to force browsers to use HTTP/1 as the protocol inside https. TLS MITM is out of the question, NFQUEUE-like usermode packet filtering may be considered at most, depending on processing overhead.
From reading the ALPN RFC it's not clear if providing an alert response or dropping the connection when I see a ClientHello that contains ALPN:http/2 will make the browser retry without ALPN.
If I understand correctly, modifying the ClientHello is out of the question as it results in a checksum error when the server responds with the ServerHello because changing the ClientHello invalidates the MAC for that packet.
Is the behavior for blocked handshakes w.r.t. ALPN the same as for handling TLS version fallback, i.e. TLS_FALLBACK_SCSV ?
EDIT: according to t1_lib.c from openssl, if the server doesn't know about ALPN, it ignores it. So if the server returns Alert for a ClientHello containing ALPN, it's probably only because it doesn't support TLS1.2, there is no way to signal to the client "please retry without ALPN" other than "alert" which results in the client trying TLS1.1.
HTTP/2 over TLS is negotiated via ALPN.
Browsers will tell to servers that they support it.
If you don't want to use HTTP/2, then you just have to modify the server configuration in a way that it doesn't have h2 as one of the protocols that it can negotiate via ALPN.
The ALPN negotiation will then fall back to HTTP/1.1 and the client will use HTTP/1.1.
Adobe documentation for AEM 6 says
"Check the Use SSL or Use TLS checkboxes when configuring the LDAP
Identity Provider."
What protocol will be used if I check both boxes? Does TLS override the SSL config option? It seems to work with one or both checked, but I can't verify which protocol was used. Is checking just TLS sufficient to ensure I have a connection using the TLS protocol?
There are 2 ways to secure LDAP connections :
One is to connect to the LDAPS port (636 by default) using SSL (or
the later TLS versions). This is the legacy and non-standard way to
do it, also generally known as "Use SSL".
One is to connect to the LDAP port (389), and then enable TLS using
the LDAP StartTLS extended operation (which negotiates SSLv3 or TLS
protocols). It is generally known as "Use TLS".
The underlying version of the protocol used (SSLv3, TLSv1.0, TLSv1.1...) depends on the settings of the LDAP server or the LDAP client library.
I hope this helps.
I'd like to restrict SSL protocols to TLS 1.2 on Vert.x 2.1.5 as http server and client. I'm using jdk 7. Does anyone have experience on how to do it?
Oracle says here that SSL protocols should be restricted on JRE 7 by explicitly setting enabled protocols on the SSL Engine:
sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"});
Now check out TCPSSLHelper.java class in Vert.x v2.1.5. There is a constant containing the list of enabled protocols, and it's used to set enabled protocols on the SSL Engine:
// Make sure SSLv3 is NOT enabled due to POODLE issue
private static final String[] ENABLED_PROTOCOLS =
{"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"};
Change that value to {"TLSv1.2"}; to limit support to TLSv1.2.
For a quick test:
Create the org.vertx.java.core.net.impl package in your own project
Copy TCPSSLHelper to your package and edit the enabled protocols constant
Build and run.
CURL using the specific protocol directives, and see that server will only connect with TLSv1.2.
Your source will typically come before third party source on the classpath, so this change will override the class in the Vert.x lib and is all you need to restrict to TLSv1.2.
Ideally this would be submitted back to Vert.x as a patch, where the protocols are read on command line as properties.
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.
Le'ts say you open a tcp socket on port 80 to handle http request, and a ssl socket on port 443 to deal with https...how can some proxy provide access to both of them on the same port??
I found only this link but it wasn't very useful. Can you provide me an erlang example or suggest me some resources from which i can learn more on the topic?
Thanks in advance
how can some proxy provide access to both of them on the same port??
By implementing the HTTP CONNECT method, the (non-transparent) proxy may switch to providing a TCP tunnel over which a browser may, for example, access an HTTPS resource.
A rather sparse specification:
https://www.rfc-editor.org/rfc/rfc2616#section-9.9
As outlined in the link you provide, you will need to write your own custom server that sniffs the request and then redirects to the correct protocol accordingly.
As http://www.faqs.org/rfcs/rfc2818.html indicates, an HTTP session will start with an Initial Request Line (e.g. GET /), whereas a TLS session will start with a ClientHello (more on the TLS session on wikipedia)
There are lots of resources online about writing servers in Erlang, e.g. How to write a simple webserver in Erlang?
Incidentally your terminology is incorrect: http, https SSL and TLS are protocols, and all operate (over the web) using TCP sockets.