OpenSSL, Stunnel

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL, Stunnel

Ron Teitelbaum

Hello all,

 

I’ve been looking into FIPS but couldn’t help falling over the Squeak Pluggin for OpenSSL and Stunnel. https://lists.wisc.edu/read/messages?id=181840

 

https://lists.wisc.edu/read/messages?id=183375

 

  I haven’t tried them yet but was wondering if anyone else has.  Does it make sense to move forward with our own FIPS certification, or would it make sense to tightly integrate both openSSL and Stunnel into squeak instead?

 

Does anyone have any thoughts about the benefits and drawbacks of having the cryptographic code be an external black box?  Are there greater benefits to our having implemented our own code, for education and flexibility …  ?  Personally I would prefer having the code be in squeak, but I thought the question worth asking.  Should we do both?

 

Thoughts?

 

Ron Teitelbaum

Squeak Cryptography Team Leader


_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL, Stunnel

Frank Shearar
"Ron Teitelbaum" <[hidden email]> wrote:

> Does anyone have any thoughts about the benefits and drawbacks of having
the
> cryptographic code be an external black box?  Are there greater benefits
to
> our having implemented our own code, for education and flexibility .  ?
> Personally I would prefer having the code be in squeak, but I thought the
> question worth asking.  Should we do both?

A quibble: stunnel _uses_ OpenSSL, so stunnel doesn't provide us with
anything more as far as crypto's concerned (at least, AFAIK). OpenSSH, on
the other hand, is quite another story. And I'd love to see those services
available in Squeak!

I think we should do both: a plugin wrapper allows us to provide strong
crypto relatively quickly. Then for True Fans, we can write Smalltalk-only
code and then either slowly phase out the plugins function by function, or
simply allow people to choose. Oh, and having plugins will provide us with
handy in-Squeak reference implementations.

My main worry with implementing our code is simply that OpenSSL and OpenSSH
have been beaten upon for a long time; while we do see advisories coming out
for them, they're few and far between.

frank

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL, Stunnel

Johnathon Meichtry
Squeak-Crypto-Gods,

I am dying (begging/praying/pleading) for a complete native Squeak
implementation of OpenSSL and OpenSSH.  They will soon be needed for the
SqueakNOS project where we don't have access to the services of an
underlying OS.  Of course SqueakNOS will be fine without it but a whole
bunch of new opportunities open up with that functionality in place.

I also agree with Franks comments that advisories are now few and far
between but of course I am saying that as someone who doesn't have the
skills to either create the port or maintain the code so it's rather too
easy for me to say ;)

Johnathon


----- Original Message -----
From: "Frank Shearar" <[hidden email]>
To: "Cryptography Team Development List"
<[hidden email]>
Sent: Thursday, July 13, 2006 8:42 AM
Subject: Re: [Cryptography Team] OpenSSL, Stunnel


> "Ron Teitelbaum" <[hidden email]> wrote:
>
>> Does anyone have any thoughts about the benefits and drawbacks of having
> the
>> cryptographic code be an external black box?  Are there greater benefits
> to
>> our having implemented our own code, for education and flexibility .  ?
>> Personally I would prefer having the code be in squeak, but I thought the
>> question worth asking.  Should we do both?
>
> A quibble: stunnel _uses_ OpenSSL, so stunnel doesn't provide us with
> anything more as far as crypto's concerned (at least, AFAIK). OpenSSH, on
> the other hand, is quite another story. And I'd love to see those services
> available in Squeak!
>
> I think we should do both: a plugin wrapper allows us to provide strong
> crypto relatively quickly. Then for True Fans, we can write Smalltalk-only
> code and then either slowly phase out the plugins function by function, or
> simply allow people to choose. Oh, and having plugins will provide us with
> handy in-Squeak reference implementations.
>
> My main worry with implementing our code is simply that OpenSSL and
> OpenSSH
> have been beaten upon for a long time; while we do see advisories coming
> out
> for them, they're few and far between.
>
> frank
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL, Stunnel

Chris Muller
In reply to this post by Ron Teitelbaum
> Does anyone have any thoughts about the benefits and drawbacks of
> having the
> cryptographic code be an external black box?  Are there greater
> benefits to
> our having implemented our own code, for education and flexibility .
> ?
> Personally I would prefer having the code be in squeak, but I thought
> the
> question worth asking.  Should we do both?

I think both is good.  Public black-box implementations are good for
those who just want to be more secure and not have to think about it.
These are much more hacked upon which is good for scrutiny, but bad
when problems are found.

FYI, someone sent me this "advisory" claiming an exposure to the RNG
used by TLS/SSL key generation.

  http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf


OTOH, I very much want to _understand_ the security, the best way for
me to do that is to get my hands dirty with our own code.  I think
understanding the why's goes far toward being able to make a secure
system.  It also seems less likely simpler, less-popular protocols
would, let alone could, be hacked since hackers probably want the glory
of breaking the "big" ones..  But this is a foolish thought to have..
:)

 - Chris

PS - One more problem with "external" black-box is its externality.
Assuming you trust the black box, you still have to release sensitive
information into the communication-pipes of the OS to get it to the
black box..  With internal security, The attacker has to hack the
memory of the image, because no sensitive information ever leaves the image.
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography