From: null@void.gov
To: ben@algroup.co.uk
Message Hash: 6dc6f024689ac6df9ba699b79e406b508e6835825f481997cc75f86c5f34d506
Message ID: <3.0.32.19961129095226.006a0428@best.com>
Reply To: N/A
UTC Datetime: 1996-11-29 17:53:03 UTC
Raw Date: Fri, 29 Nov 1996 09:53:03 -0800 (PST)
From: null@void.gov
Date: Fri, 29 Nov 1996 09:53:03 -0800 (PST)
To: ben@algroup.co.uk
Subject: Re: SAFEPASSAGE BRINGS STRONG CRYPTO TO WEB BROWSERS WORLDWIDE
Message-ID: <3.0.32.19961129095226.006a0428@best.com>
MIME-Version: 1.0
Content-Type: text/plain
I would say that depends on -where- &/or -how- you store the premaster/master,
and is dependent on platform threat models rather than attacks on the wire.
These are different problem spaces with different solutions, which some
contemplated
changes to SSL may help address: some tweaks may be useful to support more
secure secret management on the platforms. But I would not go so far as to
say
that these issues make SSL or an implementation insecure per-se, until I
did the
complete job.
If my platform is compromised such that the master or premaster secret
can be subverted, then I have problems that go way deeper than SSL or a
particular
implementation of it.
Would you like to propose some fixes? We would be very interested.
Ben Laurie wrote ....
>SSL requires the keying material to be available at all times. This is rather
>different from many applications of cryptography, where one can keep keying
>material safely locked away except when it is needed.
>
>This is the inherent vulnerability.
>
>Cheers,
>
>Ben.
>
>--
>Ben Laurie Phone: +44 (181) 994 6435 Email: ben@algroup.co.uk
>Freelance Consultant and Fax: +44 (181) 994 6472
>Technical Director URL: http://www.algroup.co.uk/Apache-SSL
>A.L. Digital Ltd, Apache Group member (http://www.apache.org)
>London, England. Apache-SSL author
>
>
Return to November 1996
Return to “null@void.gov”
1996-11-29 (Fri, 29 Nov 1996 09:53:03 -0800 (PST)) - Re: SAFEPASSAGE BRINGS STRONG CRYPTO TO WEB BROWSERS WORLDWIDE - null@void.gov