[Geoserver-devel] Some thoughts on secure transport for GeoServer (HTTPS/SSL)

GeoServer GeoServer Developer
1

Hey all,
so I've been looking at how to have GeoServer automatically switch to HTTPS when user credentials are on the fence and/or when we do have
possibly sensible information running over the wire.
The two use cases I have in mind are:
- admin console, whenever an administrator logs in and edits
   store/layer information, that should happen over SSL
- any data transfer that requires the user to authenticate
   (meaning that the user credentials are stored in http basic
   authentication headers, and that the information being
   transferred might be sensible as well).

So basically what seems to be needed is:
- have the authentication form post to an HTTPS url
- have all secure pages force a redirect to HTTPS if they
   are hit thru a non secure URL
- have all OGC service requests using http basic authentication
   switch to HTTPS by default
- have the responses asking the user to authenticate using
   HTTP basic include a redirect to HTTPS first (that is, first
   redirect to HTTPS, then tell the client that the user does not
   have enough credentials and ask for them using a HTTP 401
   response. At that point the browser will pop up a user
   credential request, but the whole communication will be
   switched to https already).

Am I missing anything?

There are two more things to discuss. The first is that the
container might not have SSL enabled. Acegi has a class
that performs redirection only if SSL is there, but it
requires one to configure the SSL ports in the application
context... bah! Not very useful as people can be using
custom ones... I'll have to find a way to make this runtime
configurable (maybe turn it into a GeoServerInfo parameter?).

The second issue is, what do we do for development and
demo (release) purposes? Setting up a SSL layer requires
one to create a certificate, a keystore and whatnot.
This guide provides some hint:
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL

I would say that for development purposes we should setup
a keystore with a well known setup and give Start.java
an option to use it, so that we can do tests with both
SSL enabled or not. The certificate will be valid for localhost
only, maybe the browser will get grumpy the first time and
ask us if we want to really trust that self signed certificate,
but from there on it should be smooth ride.

What about release? The Jetty configuration we ship with
actually has a keystore ready, one just has to include
the jetty-ssl.xml config file in the command line. Try
with:
java -DGEOSERVER_DATA_DIR=... -jar start.jar etc/jetty.xml etc/jetty-ssl.xml

and then try to connect to http://localhost:8443/geoserver
and you'll see.
We could just enable this by default but... as Arne pointed
out, it would give people a false sense of security,
since everybody knows the private key of that certificate
so it's possible to hijack those ssl communications without
much effort.
The only way to get real security is to have people
buy/create and install their own certificates...

Opinions? Help very much appreciated, I'm no security expert :wink:
Cheers
Andrea

2

I was wondering whether we could generate a hostname on startup, like SSH. However, I dont think you want a certificate without a fully qualified hostname, and asking the operating systems is probably not accurate in most cases. So that leaves prompting the user during startup.

I'd also like to point out again that a lot of users will do the HTTPS part using an Apache proxy, or a dedicated daemon like Pound. Partially because you should trust as few programs as possible with the key. So it should be possible to force redirection to HTTPS even when the container does not support SSL.

-Arne

Andrea Aime wrote:

Hey all,
so I've been looking at how to have GeoServer automatically switch to HTTPS when user credentials are on the fence and/or when we do have
possibly sensible information running over the wire.
The two use cases I have in mind are:
- admin console, whenever an administrator logs in and edits
   store/layer information, that should happen over SSL
- any data transfer that requires the user to authenticate
   (meaning that the user credentials are stored in http basic
   authentication headers, and that the information being
   transferred might be sensible as well).

So basically what seems to be needed is:
- have the authentication form post to an HTTPS url
- have all secure pages force a redirect to HTTPS if they
   are hit thru a non secure URL
- have all OGC service requests using http basic authentication
   switch to HTTPS by default
- have the responses asking the user to authenticate using
   HTTP basic include a redirect to HTTPS first (that is, first
   redirect to HTTPS, then tell the client that the user does not
   have enough credentials and ask for them using a HTTP 401
   response. At that point the browser will pop up a user
   credential request, but the whole communication will be
   switched to https already).

Am I missing anything?

There are two more things to discuss. The first is that the
container might not have SSL enabled. Acegi has a class
that performs redirection only if SSL is there, but it
requires one to configure the SSL ports in the application
context... bah! Not very useful as people can be using
custom ones... I'll have to find a way to make this runtime
configurable (maybe turn it into a GeoServerInfo parameter?).

The second issue is, what do we do for development and
demo (release) purposes? Setting up a SSL layer requires
one to create a certificate, a keystore and whatnot.
This guide provides some hint:
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL

I would say that for development purposes we should setup
a keystore with a well known setup and give Start.java
an option to use it, so that we can do tests with both
SSL enabled or not. The certificate will be valid for localhost
only, maybe the browser will get grumpy the first time and
ask us if we want to really trust that self signed certificate,
but from there on it should be smooth ride.

What about release? The Jetty configuration we ship with
actually has a keystore ready, one just has to include
the jetty-ssl.xml config file in the command line. Try
with:
java -DGEOSERVER_DATA_DIR=... -jar start.jar etc/jetty.xml etc/jetty-ssl.xml

and then try to connect to http://localhost:8443/geoserver
and you'll see.
We could just enable this by default but... as Arne pointed
out, it would give people a false sense of security,
since everybody knows the private key of that certificate
so it's possible to hijack those ssl communications without
much effort.
The only way to get real security is to have people
buy/create and install their own certificates...

Opinions? Help very much appreciated, I'm no security expert :wink:
Cheers
Andrea

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

3

Supporting this would be a very good thing, and well worth the investment.

One slight addition to the analysis: a lot of services are exposed via
firewalls and proxies - and these set-ups are often imposed across
large swathes of government by (practically) immutable and poorly
designed service contracts - in some cases https is not be available
at all (crazy but true!). This may be enforced at a proxy or the
router. Rarely are containers directly exposed.

There needs to be a flag - HTTP only, HTTPs only or mixed-mode (default)

Rob A

On Wed, Apr 15, 2009 at 6:15 AM, Arne Kepp <ak@anonymised.com> wrote:

I was wondering whether we could generate a hostname on startup, like
SSH. However, I dont think you want a certificate without a fully
qualified hostname, and asking the operating systems is probably not
accurate in most cases. So that leaves prompting the user during startup.

I'd also like to point out again that a lot of users will do the HTTPS
part using an Apache proxy, or a dedicated daemon like Pound. Partially
because you should trust as few programs as possible with the key. So it
should be possible to force redirection to HTTPS even when the container
does not support SSL.

-Arne

Andrea Aime wrote:

Hey all,
so I've been looking at how to have GeoServer automatically switch to
HTTPS when user credentials are on the fence and/or when we do have
possibly sensible information running over the wire.
The two use cases I have in mind are:
- admin console, whenever an administrator logs in and edits
store/layer information, that should happen over SSL
- any data transfer that requires the user to authenticate
(meaning that the user credentials are stored in http basic
authentication headers, and that the information being
transferred might be sensible as well).

So basically what seems to be needed is:
- have the authentication form post to an HTTPS url
- have all secure pages force a redirect to HTTPS if they
are hit thru a non secure URL
- have all OGC service requests using http basic authentication
switch to HTTPS by default
- have the responses asking the user to authenticate using
HTTP basic include a redirect to HTTPS first (that is, first
redirect to HTTPS, then tell the client that the user does not
have enough credentials and ask for them using a HTTP 401
response. At that point the browser will pop up a user
credential request, but the whole communication will be
switched to https already).

Am I missing anything?

There are two more things to discuss. The first is that the
container might not have SSL enabled. Acegi has a class
that performs redirection only if SSL is there, but it
requires one to configure the SSL ports in the application
context... bah! Not very useful as people can be using
custom ones... I'll have to find a way to make this runtime
configurable (maybe turn it into a GeoServerInfo parameter?).

The second issue is, what do we do for development and
demo (release) purposes? Setting up a SSL layer requires
one to create a certificate, a keystore and whatnot.
This guide provides some hint:
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL

I would say that for development purposes we should setup
a keystore with a well known setup and give Start.java
an option to use it, so that we can do tests with both
SSL enabled or not. The certificate will be valid for localhost
only, maybe the browser will get grumpy the first time and
ask us if we want to really trust that self signed certificate,
but from there on it should be smooth ride.

What about release? The Jetty configuration we ship with
actually has a keystore ready, one just has to include
the jetty-ssl.xml config file in the command line. Try
with:
java -DGEOSERVER_DATA_DIR=... -jar start.jar etc/jetty.xml etc/jetty-ssl.xml

and then try to connect to http://localhost:8443/geoserver
and you'll see.
We could just enable this by default but... as Arne pointed
out, it would give people a false sense of security,
since everybody knows the private key of that certificate
so it's possible to hijack those ssl communications without
much effort.
The only way to get real security is to have people
buy/create and install their own certificates...

Opinions? Help very much appreciated, I'm no security expert :wink:
Cheers
Andrea

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

Arne Kepp ha scritto:

I was wondering whether we could generate a hostname on startup, like SSH. However, I dont think you want a certificate without a fully qualified hostname, and asking the operating systems is probably not accurate in most cases. So that leaves prompting the user during startup.

That would have to be the work of the installer. GeoServer is runnig
inside a web container, and it's the web container's job to do
the SSL. GeoServer by itself cannot do anything to influence the
enviroment in which it's running.

I'd also like to point out again that a lot of users will do the HTTPS part using an Apache proxy, or a dedicated daemon like Pound. Partially because you should trust as few programs as possible with the key. So it should be possible to force redirection to HTTPS even when the container does not support SSL.

Meaning that... we need to configure where the redirection is going
somehwere in the container? Like, having the admin provide us with
a base url for https based calls, comprised of hostname, port,
and eventually a path? (a https replacement for the
http://host:8080/geoserver portion of the url?)

Cheers
Andrea