Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]

[Hubert Kario <[e-mail]>]

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