On Friday, 23 September 2016 11:59:31 CEST Stephen Farrell wrote: > On 23/09/16 11:46, Nikos Mavrogiannopoulos wrote: > > On Fri, 2016-09-23 at 09:05 +0100, Stephen Farrell wrote: > >> On 22/09/16 19:36, Yuhong Bao wrote: > >>> This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?i > >>> d=1188657 > >> > >> Yuk. Prioritising the needs of those debugging networks > >> over the maybe 5-6 orders of magnitude more folks using > >> them is ass-backwards IMO. That result looks to me like > >> a very bad decision if I'm following it correctly. > > > > That's a very different concern than the one asked by BITS security, > > and is IMO a very valid one. Running any protocol under TLS wouldn't > > mean that debugging is very hard or impossible for the one running the > > protocol. Administrators debug and trace protocols every day to figure > > out failures (that's why we have advanced tools like wireshark). Making > > it hard for them to use these tools isn't increasing security; it is > > only making their life harder. > > Sure. But their/our lives sometimes should be a bit harder > to make things safer for the vast bulk of people using the > networks/applications we're developing. As with everything, > there's a balance needed. In this case, I think the wrong > decision was reached.
those secret keys are on the client machines and they will stay on client machines making it hard to extract master key from process memory is just security through obscurity, not something that will stop a determined attacker *cough*LD_PRELOAD*cough* -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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
