Session resumption No (IDs assigned but not accepted)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I also run gnutls-cli and get:
Checking for Safe renegotiation support… yes
Checking for Safe renegotiation support (SCSV)… yes
Checking for TLS 1.2 support… no
Checking for TLS 1.1 support… no
Checking fallback from TLS 1.1 to… TLS 1.0
Checking for TLS 1.0 support… yes
Checking for SSL 3.0 support… yes
Checking for HTTPS server name… not checked
Checking for version rollback bug in RSA PMS… no
Checking for version rollback bug in Client Hello… no
Checking whether we need to disable TLS 1.0… N/A
Checking whether the server ignores the RSA PMS version… no
Checking whether the server can accept Hello Extensions… yes
Checking whether the server can accept cipher suites not in SSL 3.0
spec… yes
Checking whether the server can accept a bogus TLS record version in the
client hello… no
Checking for certificate information… N/A
Checking for trusted CAs… N/A
Checking whether the server understands TLS closure alerts… partially
Checking whether the server supports session resumption… no
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It’s strange, since I have the shared cache enabled:
## Use a SSL/TLS cache for SSL session resume.
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS
stuff and Nginx shed some light on this issue? Should I ignore this
result?
On Sun, Nov 21, 2010 at 11:43 PM, Antnio P. P. Almeida [email protected] wrote:
…
Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS
stuff and Nginx shed some light on this issue? Should I ignore this
result?
The case might be that Qualys SSL Labs checks all this against the IP
address it resolves from the domain you give them. Apply those SSL
settings to the default server to make this all work there.
If these settings are already in place or if the problem persists
after that, please post here again!
On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida [email protected] wrote:
…
Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS
stuff and Nginx shed some light on this issue? Should I ignore this
result?
The case might be that Qualys SSL Labs checks all this against the
IP address it resolves from the domain you give them. Apply those
SSL settings to the default server to make this all work there.
My default_server is used to block illegal host headers. So I have a
‘_’ as server_name. Although I have more sites running on this IP,
currently this is the only site on SSL/TLS. Isn’t this enough? Note
also that the GnuTLS client gave the same result.
On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida [email protected] wrote:
…
Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS
stuff and Nginx shed some light on this issue? Should I ignore this
result?
The case might be that Qualys SSL Labs checks all this against the
IP address it resolves from the domain you give them. Apply those
SSL settings to the default server to make this all work there.
You’re right I tried with GnuTLS against my localhost that has a
“regular” default_server and it works:
Checking whether the server understands TLS closure alerts… partially
Checking whether the server supports session resumption… yes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Also in this server there’s no setting in the config for
ssl_session_cache. Its using the default value: none.
This means that the problem resides in the way the test is performed?
Can you elaborate a little bit more?
On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida [email protected] wrote:
…
Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS
stuff and Nginx shed some light on this issue? Should I ignore this
result?
The case might be that Qualys SSL Labs checks all this against the
IP address it resolves from the domain you give them. Apply those
SSL settings to the default server to make this all work there.
Ok. I think I get it. The test doesn’t use SNI. Hence it checks
against the default_server for the session resumption test. Since in
this case this is just a regular HTTP server block with ‘_’ as server
name it doesn’t associate the server where the certficate is installed
with the session resumption test.
On Mon, Nov 22, 2010 at 01:24:01AM +0000, António P. P. Almeida wrote:
IP address it resolves from the domain you give them. Apply those
SSL settings to the default server to make this all work there.
Ok. I think I get it. The test doesn’t use SNI. Hence it checks
against the default_server for the session resumption test. Since in
this case this is just a regular HTTP server block with ‘_’ as server
name it doesn’t associate the server where the certficate is installed
with the session resumption test.
Is that it?
Session establishmen/resumption happens before SNI handling.
Therefore configuring session cache within SNI-only server{} won’t
work, you have to configure one in default server for the socket
in question.
If, on the other hand, the older session is resumed, then the
server MUST ignore the extensions and send a server hello
containing none of the extension types. In this case, the
functionality of these extensions negotiated during the original
session initiation is applied to the resumed session.
One can’t resume session stored somewhere in server name related
context while following “MUST ignore” rule.
Session establishmen/resumption happens before SNI handling.
Therefore configuring session cache within SNI-only server{} won’t
work, you have to configure one in default server for the socket
in question.
So the session resumption is done using a mapping that related IPs
with session IDs. Completely oblivious to anything related with
server_name.
If, on the other hand, the older session is resumed, then the
server MUST ignore the extensions and send a server hello
containing none of the extension types. In this case, the
functionality of these extensions negotiated during the original
session initiation is applied to the resumed session.
I tried this:
listen [::]:443 ssl default_server; # ipv6
while leaving the ‘_’ server_name for the HTTP default server. But
gnutls-bin gives the same results. No session resumption support. It
requires a regular default_server, i.e.,
listen [::]:80 default_server; # ipv6
And the session cache configured in the correct server. This means
that I must ditch the “illegal” Host header server block so it seems
in order to get SSL session resumption to work
On Mon, Nov 22, 2010 at 03:39:06AM +0000, António P. P. Almeida wrote:
in question.
containing none of the extension types. In this case, the
functionality of these extensions negotiated during the original
session initiation is applied to the resumed session.
I tried this:
listen [::]:443 ssl default_server; # ipv6
while leaving the ‘_’ server_name for the HTTP default server. But
gnutls-bin gives the same results. No session resumption support. It
requires a regular default_server, i.e.,
I’ve played a bit with this, and it seems the only working
configuration is having identical ssl_session_cache in all
SNI server{}'s.
Anything else will not work due to the fact that OpenSSL uses
initial context (i.e. default server’s one) for session caching,
but current context (i.e. server name matched server’s) e.g. to
decide whether advertise session id to client or not.
I.e. the following configuration will not cache sessions to
“test.example.com”:
ssl_session_cache off;
server {
listen 443 ssl default;
ssl_session_cache shared:SSL:10m;
...
}
server {
listen 443;
server_name test.example.com;
...
}
Additionally, when shared cache is used, nginx will be confused by
new session/remove session callbacks called with ssl connection
with context which is not expected to have any session callbacks.
E.g. this configuration will generate SIGSEGV on request to
“test.example.com”:
server {
listen 443 ssl default;
ssl_session_cache shared:SSL:10m;
...
}
server {
listen 443;
server_name test.example.com;
ssl_session_cache builtin;
...
}
Simpliest (and recommended) workaround for both problems is to use
ssl_session_cache defined at http{} level. I.e.
ssl_session_cache shared:SSL:10m;
server {
...
}
...
I’ve played a bit with this, and it seems the only working
configuration is having identical ssl_session_cache in all
SNI server{}'s.
I’ve re-updated the Wiki and indicated that as the preferred
approach.
server {
}
server {
listen 443;
server_name test.example.com;
ssl_session_cache builtin;
…
}
Simpliest (and recommended) workaround for both problems is to use
ssl_session_cache defined at http{} level. I.e.
I’ve re-updated the Wiki and indicated that as the preferred
approach.
Going off in a tangent. Does the usage of GNU TLS instead of OpenSSL
as the underlying crypto library might mitigate this? There’s now a
mod_gnutls for Apache. And it would be nice if Nginx had also
“competing” crypto modules. Just an idea.
Thanks,
— appa
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
