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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to