[Seaside-dev] Re: Seaside Security

[Paul DeBruicker]

Hi Phillipe,  

Thanks for starting this discussion.  

It seems reasonable to me that if you're proxying from a webserver to
seaside then the webserver could/should take care of the HSTS header and
terminate the SSL connections.  Moving that work to Squeak/Pharo when
unnecessary seems sub optimal.  


For reading /dev/urandom to use as a seed we'd need FFI or OSProcess,
correct? If we have those could we just get cryptographically secure random
numbers without an in image PRNG?

On windows the urandom equivalent is:
https://en.wikipedia.org/wiki/CryptGenRandom (I've never used it for
anything)

I think it would be nice to not require FFI, OSProcess, or access SqueakSSL
but use them if available and performance is sufficient.   I know the
SqueakSSL plugin is included with Eliot's and the pharo vm now.  Maybe it'd
be simplest to add the ability to access random bytes from OpenSSL to the
SqueakSSL plugin.  

For a pure in image solution it sounds like what you would like is a
refactoring of the Cryptography package into subprojects then integrating
the PRNG's into Seaside.  I don't know what that would take.  There was a
discussion on the Crypto mailing list from November about the RNGs and
splitting the big package both of which appear partially finished in some
way:

http://lists.squeakfoundation.org/pipermail/cryptography/2013-November/000674.html


hope this helps

Paul



Philippe Marschall wrote
> Hi
> 
> Having had a few too many security reviews and secure coding events in
> the past we days I started working on a Seaside-Security package. The
> idea behind the package is that it contains things that you can add it
> to your application to make it more secure. It doesn't contain things
> that we can add by default because they have to be configured
> specifically for your application. Right now the plan is for it to
> contain two things:
>  * filters that add additional headers (Content-Security-Policy,
> X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security)
>  * key generators for cryptographically secure session ids for
> Pharo/Squeak
> The filters would mean that the current
> WAStrictTransportSecurityFilter is moved from Seaside-Core to
> Seaside-Security and #iMeanIt is moved from Seaside-InternetExplorer
> to Seaside-Core. A limitation of the current
> WAStrictTransportSecurityFilter is that when reverse proxying it's
> hard to find out whether the original request was made with HTTPS or
> HTTP. AJP is the only adapter that I know of that finds this out
> reliably. Swazoo could find it out when not proxying but I don't know
> whether anybody uses this. CGI could in theory find it you but I don't
> know whether this is done currently.
> I don't know what the other platforms do but neither Pharo nor Squeak
> seem to ship a cryptographically secure PRNG. Therefore it's hard for
> Seaside to provide cryptographically secure session ids on these
> platforms so we don't do it (we could implement SHA1PRNG since we have
> SHA-1 on GRPlatform). We could in theory use OpenSSL RAND_bytes but
> the SqueakSSL plugin doesn't seem to provide access to it. This leaves
> us more or less with the Cryptography package [1]. It implements two
> cryptographically secure PRNGS: SHA1PRNG and Fortuna. I'm not super
> exited about this package. It's huge, contains failing tests and as
> far as I can tell you're somehow supposed to come up with a good seed
> on your own (we can just read from /dev/random on Unix but what do we
> do on Windows). If anybody knows of any better options please speak
> up.
> 
>  [1] http://smalltalkhub.com/#!/~Cryptography/Cryptography
> 
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list

> seaside-dev at .squeakfoundation

> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev





--
View this message in context: http://forum.world.st/Seaside-Security-tp4742433p4742665.html
Sent from the Seaside Development mailing list archive at Nabble.com.