On Saturday, 9 June 2018 03:13:29 CEST Christian Huitema wrote: > On 6/8/2018 7:35 AM, David Benjamin wrote: > > On Fri, Jun 8, 2018 at 10:07 AM R duToit <r@nerd.ninja> wrote: > > > GREASE values should not make their way into code. The whole > > > > point is to get code used to the fact that unknown values exist. > > > > The GREASE mechanism is useful, but it will definitely make its > > way into code and become ossified itself. > > Example: https://github.com/salesforce/ja3 > > > > Indeed. GREASE was targeting normal sensible endpoint implementations... > > ... and maybe we need a different mechanism to defeat fingerprinting > tools like this JA3 project. Maybe applications need to somehow > randomize their signatures, so that they are not so easy to recognize. > For example, it should be possible to use randomize the order of > extensions. And it should also be possible to throw some grease in these > sets. > > Of course, the first ones to develop and use these randomization > techniques will most likely be the malware authors that the tools are > allegedly trying to track.
you can probe implementations irrespective of enabled ciphers, just by looking at the way they handle errors: https://github.com/WestpointLtd/tls_prober -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
