[QUESTION] Enable specific version of TLS

sscarduzio · January 2, 2018, 3:49pm

Hi @askids I completely rethought this feature for the older versions i.e. 5.1.x up to 5.6.x because the old Netty they used didn’t have an explicit way to set protocols.

Now the 5.x SSL stack uses the same approach as SG (creates a new SSL engine per connection). That means we have the possibility to freely set up the protocols and ciphers directly into the SSL engine.

I didn’t measure, but this technique may be a tiny tad slower than what ROR used to do. However, it won’t affect all the 6.x builds.

https://readonlyrest-data.s3-eu-west-1.amazonaws.com/build/1.16.15-pre6/readonlyrest-1.16.15-pre6_es5.5.1.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJEKIPNTOTIVGQ4EQ/20180102/eu-west-1/s3/aws4_request&X-Amz-Date=20180102T154821Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=3d1df89c20b2516075a36cdfea6679b9f6d6383fbe66509ffb1e04e4664a058f

askids · January 2, 2018, 11:23pm

Finally it worked with the new version. But from the logs, its not clear which version of TLS is being enforced. On the allowed_protocols, I just had TLSv1.2. Previously, I used to get message like “ROR SSL accepted protocols: TLSv1.2”. But now the log entry simply says restricting to TLSv1,TLSv1.1,TLSv1.2. So it is not very clear if the parameter got accepted or not.

Also, when restricting the cipher, I am assuming the supported list changes based on what protocol setting that we use. So you might want to test it out to see if someone give unsupported cipher for the protocol used OR gives a list of ciphers and 2 protocols, some supported one version and other on other version. In our environment, for most applications, we are being asked to allow backward compatibility, but default to v1.2 on the application side. So there might be similar requirements later on for ROR as well where users might end up using a combination of protocols. So probably that is a scenario, that you will need to validate. In our case, we are going to use only TLSv1.2 for ROR as our application is the only consumer.

[2018-01-02T18:05:47,113][INFO ][t.b.r.e.SSLTransportNetty4] Loaded good settings from D:\Apps\Program Files\Elasticsearch-5.5.1\config\readonlyrest.yml
[2018-01-02T18:05:47,309][INFO ][t.b.r.e.SSLTransportNetty4] creating SSL transport
[2018-01-02T18:05:47,311][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: attempting with JKS keystore..
[2018-01-02T18:05:47,313][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Discovered key from JKS
[2018-01-02T18:05:47,313][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Discovered cert chain from JKS
[2018-01-02T18:05:47,394][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Using SSL provider: JDK
[2018-01-02T18:05:47,397][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Available ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,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
[2018-01-02T18:05:47,397][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Restricting to ciphers: TLSv1,TLSv1.1,TLSv1.2
[2018-01-02T18:05:47,397][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Avaliable SSL protocols: TLSv1,TLSv1.1,TLSv1.2
[2018-01-02T18:05:47,398][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Available ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,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

Also, not to be picky - “Avaliable SSL protocols” - Available is spelled incorrectly

sscarduzio · January 3, 2018, 5:05pm

Yes please be picky, it’s much appreciated. Thanks!

For now, without OpenSSL, we can’t influence the protocol negotiation because we can’t use NPN or ALPN. We can just specify an unordered list of accepted protocols and ciphers.

I corrected the bugs you found in the logging:

[2018-01-03T10:09:38,683][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Available ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,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
[2018-01-03T10:09:38,684][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Restricting to ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[2018-01-03T10:09:38,684][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Available SSL protocols: TLSv1,TLSv1.1,TLSv1.2
[2018-01-03T10:09:38,685][INFO ][t.b.r.e.SSLTransportNetty4] ROR SSL: Restricting to SSL protocols: TLSv1.2

A new build is on the way!

sscarduzio · January 3, 2018, 8:10pm

Hey @askids, here is the pre7 build for 5.5.1.

askids · January 3, 2018, 9:48pm

Thanks @sscarduzio. Looks good now. I tried enabling only 1.2 for ROR, disabled 1.2 on my browser and tried hitting the ES endpoint and got the page cannot displayed. After that i added 1.1 to ROR allowed protocols and was able to get to the ES endpoint. So we are good with this version. Tested on Win 2012 R2. I will test it on Win 2008 R2 tomorrow.

Also, you mentioned that this might be bit slower than previous implementation. Are you planning to run any benchmarks before releasing the final build?

sscarduzio · January 4, 2018, 6:59pm

I had an informal benchmark on my laptop on ES 5.6.3 (the less optimised SSL stack only affects sub 6.0 versions of ES).
I measured a 15% decrease of average requests/s between 1.16.14 (standard ROR SSL) and 1.16.15-pre8 (SearchGuard-style , one SSL per connection) with the following conditions:

Simple GET /
400 parallel HTTPS Connections
I ran the test 4 times for each version and elected the best result.

sscarduzio · January 4, 2018, 7:02pm

I think it’s acceptable because it affects old versions and unlocks the protocol and cipher selection. Also because it’s tested on GET / which is unrealistically quick to serve for ES, since it does not touch storage.

What do you think?

askids · January 4, 2018, 11:09pm

When you say it impacts only sub 6.0 version, currently it will be mostly entire ES user base as not many would have moved to 6.x version So I am assuming this will happen irrespective of whether allowed protocols feature is used OR if ROR defaults to server default. Is that correct assumption?

For us, the throughput will be acceptable as our user base is small and we will be coming from an avg 3 second search from current application to sub-second search response via ES. So our user base will definitely not see this difference.

Do you want to get a second opinion from one of the other ROR users?

sscarduzio · January 4, 2018, 11:30pm

15% degradation benchmarked on localhost, without accessing storage… I think it’s not big deal. Plus, it’s not affecting the 3 newest ES releases. I’d move forward.

askids · January 5, 2018, 12:31am

Ok. I will look forward for the final release so that we can integrate it in higher lanes. Thanks for adding this feature!

sscarduzio · January 5, 2018, 12:36am

No thanks for driving this, it’s quite a nice feature to have!