Re: SAFEPASSAGE BRINGS STRONG CRYPTO TO WEB BROWSERS WORLDWIDE
![](https://secure.gravatar.com/avatar/ede69d799fd42f10561257e707accf61.jpg?s=120&d=mm&r=g)
At 07:12 AM 11/27/96 +0000, you wrote: .....etc Can you be more specific? What are the vulnerabilities you are aware of?
I've never seen a security review of SSLeay, and if anyone gave it a clean bill of health, they didn't have their eye on the ball. Note, I'm not knocking SSLeay here, it is a wonderful lump of code, but it hasn't been written with security in mind (IMHO).
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
![](https://secure.gravatar.com/avatar/a706404d3a198d273fec734d269fd323.jpg?s=120&d=mm&r=g)
geeman@best.com wrote:
At 07:12 AM 11/27/96 +0000, you wrote: .....etc Can you be more specific? What are the vulnerabilities you are aware of?
I think I would discuss this with the author before going public, to give him the usual opportunity to clean up before all hell breaks loose. However, that is what I'd call "work" rather than "fun", so I'd want paying for it. No doubt I'll take it up with Eric at some point, when neither of us has anything better to do. My impression is that Eric is more interested in speed and functionality than strict security (and considering the incredible vulnerability that is more or less inherent in an SSL implementation, I feel the same). I could be wrong, of course. I will say that I'm not aware of any problems that a good firewall and physical security don't take care of. That isn't to say there aren't any - I haven't looked that hard. Cheers, Ben.
I've never seen a security review of SSLeay, and if anyone gave it a clean bill of health, they didn't have their eye on the ball. Note, I'm not knocking SSLeay here, it is a wonderful lump of code, but it hasn't been written with security in mind (IMHO).
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
-- 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
![](https://secure.gravatar.com/avatar/077760255cf9fee393d639f93481b233.jpg?s=120&d=mm&r=g)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
I think I would discuss this with the author before going public, to give him the usual opportunity to clean up before all hell breaks loose. However, that is what I'd call "work" rather than "fun", so I'd want paying for it.
Translation: You don't really know what you are talking about.
My impression is that Eric is more interested in speed and functionality than strict security (and considering the incredible vulnerability that is more or less inherent in an SSL implementation, I feel the same). I could be wrong, of course.
How is any security hole inherent in an SSL implementation? The protocol itself may not give you everything you need, but regardless of whether or not the protocol is useable for any given task (or any task at all), nothing precludes a secure implementation.
![](https://secure.gravatar.com/avatar/a706404d3a198d273fec734d269fd323.jpg?s=120&d=mm&r=g)
Anonymous wrote:
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
I think I would discuss this with the author before going public, to give him the usual opportunity to clean up before all hell breaks loose. However, that is what I'd call "work" rather than "fun", so I'd want paying for it.
Translation: You don't really know what you are talking about.
My impression is that Eric is more interested in speed and functionality than strict security (and considering the incredible vulnerability that is more or less inherent in an SSL implementation, I feel the same). I could be wrong, of course.
How is any security hole inherent in an SSL implementation? The protocol itself may not give you everything you need, but regardless of whether or not the protocol is useable for any given task (or any task at all), nothing precludes a secure implementation.
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
![](https://secure.gravatar.com/avatar/a706404d3a198d273fec734d269fd323.jpg?s=120&d=mm&r=g)
Anonymous wrote:
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
I think I would discuss this with the author before going public, to give him the usual opportunity to clean up before all hell breaks loose. However, that is what I'd call "work" rather than "fun", so I'd want paying for it.
Translation: You don't really know what you are talking about.
I know that personal attacks are the currency on this list, but I may as well point out that it is precisely because I do know what I'm talking about that I can reasonably expect to be paid to do the talking. 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
participants (3)
-
Ben Laurie
-
geeman@best.com
-
lucifer@dhp.com