|
Hi Cullen, On Sunday, 10 July 2022 at 11:41, Cullen Jennings <fluffy@xxxxxx> wrote: > > On Jul 8, 2022, at 9:37 AM, Thomas Fossati <Thomas.Fossati@xxxxxxx> wrote: > >
> > I keep an eye on data from a cute crawler [0] that regularly scans > > the top 1 million web sites, and twice per year makes a summary of > > the trends. (You can find the freshly collected raw data [1] as > > well as the most recent summary [2].) > >
> > What I gather from that data set is that the amount of traffic < 1.2 > > is becoming quasi invisible (*). So I would be really surprised if > > Mozilla, Apple and Google, which are surely captured by the crawler, > > were among the very few caught red-handed supporting ver
∈ [1.0, > > 1.1]. > >
> > Very interesting. I think this is important that we get to the bottom > of this because the data you are basing some of your conclusions on > looks wrong to me.
> > I’m reading
> https://scotthelme.co.uk/top-1-million-analysis-november-2021/
> and there is a section labeled "TLS, old and new” which has a table > that lists TLS 1.1 at zero.
> > It also references a more specific file at > https://crawler.ninja/files/protocols.txt which currently has the > following in that file > > TLS Protocol Versions: > TLSv1.3 386,472 > TLSv1.2 179,549 > TLSv1.0 515 > > Again implying 1.1 is at 0. If this is supposed to represent the > number of sites that offer 1.1, out of the top million, well, I think > it wrong. I also don’t think what web sites are are offering a given > version is a very great metric to estimate what non browsers TLS > client applications are using but that is a different issue.
> > I think it is pretty critical that we sort out. > > Here is what that site lists as top 10 sites ( I disagree it is the > top 10 by clients that use it but close enough for some data )
> > 1,google.com > 2,akamaiedge.net > 3,facebook.com > 4,youtube.com > 5,gtld-servers.net > 6,netflix.com > 7,microsoft.com > 8,instagram.com > 9,twitter.com > 10,akamai.net > > I checked if they support TLS 1.1 with a command like " openssl > s_client -connect google.com:443 -tls1_1 “. What I got from Calgary > on July 9 is
> > 1,google.com YES > 2,akamaiedge.net (this is not a valid server so I randomly used > e673.dsce9.akamaiedge.net) YES > 3,facebook.com NO > 4,youtube.com YES > 5,gtld-servers.net ( seriously, I don’t think this is the #5 domain by > any sane definition ). Anyways, I can’t find where it does TLS so will > ignore it. UNKNOWN > 6,netflix.com YES > 7,microsoft.com NO > 8,instagram.com YES > 9,twitter.com NO > 10,akamai.net (I used e1699.dscx.akamaiedge.net ) YES > > This looks like well over half of that top 10 list support TLS 1.1 > which matches up with other data I have seen.
> > What is your thoughts on why it is still turned on for that many ? I > think the answer to that question could provide some really useful > information for this draft.
That's interesting indeed, and you are right. At least the top-10 behaves in a very different way from what is reported. I'll get in touch with the crawler's author to check whether there's a problem with the crawler itself, or it's just that top-n behaves vastly differently compared to the bottom 1000000-n. But to be 100% clear, the text in the draft is not based on the crawler.ninja measurements (that's purely one data set that *I* have been looking at due to my fixation on HTTPS trends); here we are purely echoing what the IETF consensus about version support/deprecation is. > Just so I am not taken the wrong way here, I am not at all arguing > that SHA1 is fine for TLS. The advice I give people is put together a > threat model for your use of TLS, figure out which, if any clients > would be impacted by going to version X, and make a rational decision > about if you should move to requiring version X. If your client are > all safari or chrome in US or EU on smart phones that are within the > apple software update window, the cost of moving might be nearly zero > - if you are supporting very old, very cheap mobile phones globally, > your stats are going to be a bit different. If what you are > transferring over TLS is a web page with a menu for your restaurant, > your risk of using SHA1 might be pretty much zero. This draft can help > provide that information for people to, as Spencer says, make good > choices. I’d love to see the draft have more of that for this TLS 1.0 > / 1.1 issue.
> > I am also not arguing in any way that TLS 1.1 is not deprecated at the > IETF. It is.The IETF published an RFC that said don’t use it. However > deployments with excellent networking and security teams, like > companies on the above list, are still supporting it for some use > cases which makes me think it would be far more useful to provide some > information about the risk and reasons to use it and not to use it. > That would help people understand in a way that may have more impact > in getting a transition to newer version that just another RFC that > also says don’t use it with no extra info.
> > We end up with some people saying “www.google.com” supports TLS 1.1 > and if it is good enough for them, it works for me. But is far more > subtle than that. The endpoints for google pay at pay.google.com do > not support 1.1 even thought 1.1 might be fine for some of the > www.google.com. This gets lost on people.
> > I think there is room for additional useful information here. I’m not > volunteering to write such advice, done is feature, and I am thankful > to the people that created what is in the draft. I think the task of this BCP is to provide *security* best practices to the community of operators and implementers. If we were to phrase it in a more nuanced way as you suggest I think we'd dilute a message that needs to be strong and clear. I trust people not to base their choice solely on this specific source; they will balance the security risks (which this document will hopefully help inform) with their users' reach and any further consideration they need to factor in to their deployment decisions. My two cents, obviously. cheers, t |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
