zlacker

[parent] [thread] 8 comments
1. wging+(OP)[view] [source] 2022-07-09 02:25:26
> Unlike CF, AWS does not support TLS1.3. This is not working while HN uses the AWS IP.

This seemed implausible so I looked into it, and it's wrong as stated (at best, it needs to be made more precise to capture what you intended). First, you've mentioned Cloudflare, but the equivalent AWS product (CloudFront) does support TLS 1.3 (https://aws.amazon.com/about-aws/whats-new/2020/09/cloudfron...).

HN isn't behind CloudFront, though, so you probably mean their HTTP(s) load balancers (ALB) don't support TLS 1.3. Even that's an incomplete view of the load balancing picture, since the network load balancers (NLB) do support TLS 1.3, https://aws.amazon.com/about-aws/whats-new/2021/10/aws-netwo....

replies(3): >>Aeolun+g1 >>1vuio0+DG >>19h+v81
◧
2. Aeolun+g1[view] [source] 2022-07-09 02:33:15
>>wging+(OP)
NLB’s support everything that goes over TCP or UDP, that’s not exceptionally surprising.
replies(1): >>WatchD+94
◧◩
3. WatchD+94[view] [source] [discussion] 2022-07-09 02:53:08
>>Aeolun+g1
Yeah but NLB can offload TLS from the app, which is what the parent commenter linked to. It’s not just passing through the TLS from the app(which is also possible).
◧
4. 1vuio0+DG[view] [source] 2022-07-09 09:45:02
>>wging+(OP) 

   echo|bssl s_client -connect 50.112.136.166:443 -min-version tls1.3

   Connecting to 50.112.136.166:443
   Error while connecting: TLSV1_ALERT_PROTOCOL_VERSION
   94922006718056:error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION:/home/bssl/boringssl-refs-heads-master/ssl/tls_record.cc:594:SSL alert number 70
replies(2): >>pgCKIN+8J >>wging+xN1
◧◩
5. pgCKIN+8J[view] [source] [discussion] 2022-07-09 10:16:31
>>1vuio0+DG
For a moment I thought about a SNI issue but no, you are right:

Version: 2.0.7 OpenSSL 1.1.1n 15 Mar 2022

Connected to 50.112.136.166

Testing SSL server news.ycombinator.com on port 443 using SNI name news.ycombinator.com

  SSL/TLS Protocols:
SSLv2 disabled SSLv3 disabled TLSv1.0 enabled TLSv1.1 enabled TLSv1.2 enabled TLSv1.3 disabled
◧
6. 19h+v81[view] [source] 2022-07-09 14:02:09
>>wging+(OP)
TLS 1.3 needs to be explicitly enabled in CloudFront
replies(1): >>Matthi+UM1
◧◩
7. Matthi+UM1[view] [source] [discussion] 2022-07-09 18:00:54
>>19h+v81
No - it's enabled by default for all available security policies. CloudFront allows to configure the minimum TLS version - the maximum is always TLS1.3.

https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

However HN is not using CloudFront - so this doesn't matter for evaluating why HN is not supporting TLS1.3

◧◩
8. wging+xN1[view] [source] [discussion] 2022-07-09 18:04:22
>>1vuio0+DG
That still doesn't mean you can't use TLS 1.3 on AWS. For example, I have a Cloudfront-based site I haven't touched in years that works just fine with TLS 1.3.
replies(1): >>1vuio0+zQ2
◧◩◪
9. 1vuio0+zQ2[view] [source] [discussion] 2022-07-10 04:04:20
>>wging+xN1
"Unlike CF, AWS does not support TLS1.3. This is not working while HN uses the AWS IP."

The context of the above statement was the HN site, not every site that uses AWS.

Specifically, I mean that if HN uses CF, then TLS1.3 will be supported. (Before the outage I accessd HN through CF so I could use TLS1.3, because the M5 hosted site did not support it.) Whereas if HN uses AWS, then TLS1.3 may or may not be supported. As it happens, there is no support.^1

Not being more clear is on me and I apologise that the statement was misinterpreted. Nevertheless, the fact that there are other sites accessed through AWS that support TLS1.3 does not help the HN user here who wants to use TLS1.3, namely, me. That is the context of the comment: accessing HN using TLS1.3. It is not a review of AWS. It is a statement about accessing HN with TLS1.3.

1. For example, those using Cloudfront CDN services.

[go to top]