Seaside Security

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 09 Feb 2014, at 14:37, Philippe Marschall <[hidden email]> wrote:

> If anybody knows of any better options please speak
> up.

There is a possibility to just harvest a part of the code of the Cryptography package.
For example, for the implementation of Json-Webtoken on Gemstone, I extracted the code for SHA256 only.

It's not an ideal action (understatement), but given the state of the Cryptography package, it may be the simplest thing to do.

Johan_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Sun, Feb 9, 2014 at 2:37 PM, Philippe Marschall
<[hidden email]> wrote:
Crypto-Nacl [1] seems to offer access to random bytes as well but I
can't find an RNG.

 [1] http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 10 Feb 2014, at 19:47, Paul DeBruicker <[hidden email]> wrote:

> For reading /dev/urandom to use as a seed we'd need FFI or OSProcess,
> correct?

No:

'/dev/random' asFileReference
  readStreamDo: [ :stream |
    stream binary; next: 10 ]

=> #[111 170 202 225 218 206 40 167 94 165]

Just like that, as secure as your OS I guess.

Sven
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Ahh, thanks Sven.

Sven Van Caekenberghe-2 wrote

On 10 Feb 2014, at 19:47, Paul DeBruicker <[hidden email]> wrote:

> For reading /dev/urandom to use as a seed we'd need FFI or OSProcess,
> correct?

No:

'/dev/random' asFileReference
  readStreamDo: [ :stream |
    stream binary; next: 10 ]

=> #[111 170 202 225 218 206 40 167 94 165]

Just like that, as secure as your OS I guess.

Sven
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Mon, Feb 10, 2014 at 7:47 PM, Paul DeBruicker <[hidden email]> wrote:
> 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

In a way yes. The whole SSL configuration needs to be done on the
frontend webserver so you may as well do STS there. OTOH when the
frontend webserver modifies the the response that's always a bit
intransparent magic.

> and terminate the SSL connections.

Yes

> Moving that work to Squeak/Pharo when
> unnecessary seems sub optimal.

We're just talking about adding another HTTP header.

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

My understanding is it's the equivalent of /dev/random, not
/dev/urandaom. It's my understanding that /dev/random is preferable
for seeds. But I don't know enough about FFI to know how I should call
this function.

> 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.

I'm fine with anything that does not require installing additional plugins.

> Maybe it'd
> be simplest to add the ability to access random bytes from OpenSSL to the
> SqueakSSL plugin.

AFAIK we'd have to extends the OpenSSL plugin and wait for VM builds.

> 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:

The size of the package is merely a "cosmetic" flaw. My biggest issue
is that the RNGs aren't usable out of the box and you have to come up
with a seed yourself (at least that's my understanding).

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Phillipe wrote:
>(we can just read from /dev/random on Unix but what do we
>do on Windows)

For windows there is CryptGenRandom (from CAPI) [1], should not be too hard to
provide for Windows. Here is a C/C++ example:

  https://gist.github.com/kbjorklu/6317361

It is different on Smalltalk platform and OS platform to wrap a native API.

It can be wrapped using NativeBoost in Pharo, ideally as a security/cryptography
package in the general http://smalltalkhub.com/#!/~OS/OS-Windows

For VW this can be done using DLLC Connect, FFI on Squeak, ...

Merely (as always) just a time issue.

Thx
T.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Wed, Feb 12, 2014 at 2:46 PM, Torsten Bergmann <[hidden email]> wrote:
Not only. It have no idea at all how to do this in Pharo/Squeak. Can
you point me to a good tutorial?

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

I just read this on HN, about seeding a PRNG:

From the Canyon Edge: Improving Random Seeds in Ubuntu 14.04 LTS Cloud Instances

http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html

Of course there are old and new web services doing this, as web framework Seaside should use them !

ZnClient new get: 'https://entropy.ubuntu.com'.
ZnClient new get: 'http://www.random.org/cgi-bin/randbyte?nbytes=10&format=h'.

Sadly, the first call only works on Linux, not on Mac OS X, due to certificate problems.

On 10 Feb 2014, at 19:52, Sven Van Caekenberghe <[hidden email]> wrote:

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Tue, Feb 18, 2014 at 11:34 PM, Sven Van Caekenberghe <[hidden email]> wrote:
> I just read this on HN, about seeding a PRNG:
>
> From the Canyon Edge: Improving Random Seeds in Ubuntu 14.04 LTS Cloud Instances
>
> http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html

That article seems to suggest that sometimes it's better to use
/dev/urandom as a seed instead of /dev/random

> Of course there are old and new web services doing this, as web framework Seaside should use them !

I generally don't like frameworks that connect to the Internet. It can
also cause trouble in certain enterprise environments (but then what
doesn't).

> ZnClient new get: 'https://entropy.ubuntu.com'.

Uh oh, this seems to be AGPL.

> ZnClient new get: 'http://www.random.org/cgi-bin/randbyte?nbytes=10&format=h'.
>
> Sadly, the first call only works on Linux, not on Mac OS X, due to certificate problems.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev