Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
>> [0] "In principal" because there's a fair bit of SCADA gear that does this
>> because it doesn't have the CPU power to generate new DHE values, as I
>> found out when I turned on non-DHE checking some years ago.
>
>Is this SCADA gear running TLS 1.3? is it clients and servers both, or just
>one or the other? When was this scan done? i'd love to see more
>documentation about this practice.
No, it'd be mostly 1.0, moving slowly to 1.2 at some stage (I spend a fair
chunk of yesterday debugging a handshake failure that turned out to be the
fact that the current, most-recent release of the code in a fairly significant
code base can't understand anything newer than TLS 1.0). It wasn't a rigorous
scan, it just got enabled for a new release and then there were enough
complaints about it breaking things that it got removed again.
I don't really know if it's possible to do any kind of useful survey of the
SCADA environment because most of it is invisible to the public internet, you
just try various things on a small basis and if no-one complains, push it out
to more and more users and hope you don't get complaints. Sometimes things
break, for example within the last month we had a customer who thought "USA"
was a valid ISO 3166 country code:
231 12: SET {
233 10: SEQUENCE {
235 3: OBJECT IDENTIFIER countryName (2 5 4 6)
240 3: PrintableString 'USA'
: }
: }
Since no-one seems to check whether the C= component in a DN is a valid
country or even looks like a valid C= component, it hadn't been noticed
before. No idea what would have ended up in there if they were in Saint
Vincent and the Grenadines or the Federated States of Micronesia.
Anyway, I don't have any real data, just that it was common enough that we had
to remove the check again. When I talk about SCADA stuff and it sounds rather
anecdotal that's because it usually is, you enable a new feature and if you
don't get complaints, leave it enabled, but that's as far as it goes in terms
of coverage.
Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
