Showing posts with label https. Show all posts

Thursday, 14 February 2019

Nginx - Redirecting to HTTPS

For automatic http->https redirection it is recommended to use Apache or Nginx in front of Payara to do the redirection, see [1].

I decided on using nginx for this^{2 3 4}.

Before nginx, it looks like this:

$ curl -s -D - http://www.mrbear.org -o /dev/null
HTTP/1.1 200 OK
Server: Payara Server 5.184 #badassfish
X-Powered-By: Servlet/4.0 JSP/2.3 (Payara Server 5.184 #badassfish Java/Oracle Corporation/1.8)
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
X-Frame-Options: SAMEORIGIN

Configuration is found in /etc/nginx/nginx.conf.

I changed it into something very simple:

server {
      listen      80 default;
      access_log off;
      error_log off;
      return      301 https://$server_name$request_uri;
}

Double checking:

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Enabling automatic start and also starting nginx.

# systemctl enable nginx
# systemctl start nginx

So, let's try seeing what the webserver now responds with:

$ curl -s -D - http://www.mrbear.org -o /dev/null
HTTP/1.1 301 Moved Permanently
Server: nginx/1.12.2
Date: Mon, 28 Jan 2019 16:28:59 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: https://www.mrbear.org/

$ curl -s -D - http://www.mrbear.org/this/is/some/url.jsf -o /dev/null
HTTP/1.1 301 Moved Permanently
Server: nginx/1.12.2
Date: Mon, 28 Jan 2019 16:31:06 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: https://www.mrbear.org/this/is/some/url.jsf

References

[1] Payara - How to Secure Payara Server with Apache: https://blog.payara.fish/how-to-secure-payara-server-with-apache
[2] How To Nginx Redirect All HTTP Request To HTTPS Rewrite 301 Rules: https://www.cyberciti.biz/faq/linux-unix-nginx-redirect-all-http-to-https/
[3] How to do an Nginx redirect: https://bjornjohansen.no/nginx-redirect
[4] Creating NGINX Rewrite Rules: https://www.nginx.com/blog/creating-nginx-rewrite-rules/
DigitalOcean - How To Install Nginx on CentOS 7: https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-centos-7

Friday, 19 February 2016

Front end update: Angular 2.0 & HTTP/2

I have taken up learning Angular, yet it seems that a new angular is being prepared, Angular 2¹. Angular 2 seems to be a complete rewrite, and has a very different architecture. For one thing, it can work with ECMAScript 6 and TypeScript.

Luckily, I managed to be at a small session regarding Angular 2 at Quintor, today, Thursday the 18th of February 2016.².

As a matter of fact, I am writing this blog in the train home.

HTTP/2

The speaker was Martijn van Campenhout of Quintor. The first presentation was regarding the new HTTP/2 protocol (officially released in May 2015), which is rapidly replacing the old HTTP/1.1 version (released in 1996). It is based on the SPDY implementation developed by Google in 2010 and officially submitted for standardisation.

Statistics shown by Mozilla indicate that an decrease of pageload times of 2.2 seconds, results in an increase of Downloads by about 15%.^{3 4}

Old tips and tricks

The old tips and tricks that are used to deal with the defficiencies of HTTP/1.1 and the lack of bandwith and troubles with latency were:

combining files as much as possible
inlining everything
minifying everything
domain sharding
using sprite files
define critical CSS and JS files
using GZIP

These different tactics are used to make sure the Webbrowser has to do a minimum number of requests and does not need to get a lot of data to the user.

It seems the Chrome browser development tools has excellent support for simulating bad connections or large latency, using a variety of set network connection types.

Another common tactic was to display/render only those parts of the web page that are visible to the user. Once the user starts scrolling, the parts that scroll into the viewscreen of the user are downloaded and rendered. This is called "the Fold"⁵, and is a common DTP term.

There was a most impressive demonstration, where a picture consisting of about 100 smaller pictures was being shown, with a one second delay (latency) between the request and the response for a smaller picture. The difference between HTTP/1.1 and HTTP/2 was very big. Where the Browser only allows 8 concurrent connections with HTTP/1.1 causing a severe bottleneck, a single connection using HTTP/2 was more than enough to show the entire picture in about a second.

The tactics used for HTTP/2 can be summed up as follows:

Multiplexing: different Streams of data (files, css, images, html, javascript) across the same HTTP connection
Priority: allowing a setting of priority based on content. For example that the big logo should be loaded first, and the little icons at the bottom of the page last.
Binary Headers: easier and quicker to parse, fixed length, unambiguous
HPACK: In the past headers were not compressed, this has now changed.
Server push: server remembers the combination of files requested. One file request will trigger the others automatically.

This is also the first time that I heard the term CRIME, "Compression Ratio Info-leak Made Easy". Basically it boils down to a man-in-the-middle-attack, adding stuff to a message to see if it increased the compressed file. If it does not, the item added already was part of the file, and he has learned something valuable regarding the message.

The HTTP/2 is already incorporated in Apache server, NGINX. Servlet specification 4.0 of Java EE 8 will have support for it (JSR-369).

Criticisms

There were some criticisms regarding HTTP/2, though.

It seems the HTTP/2 might just be available only using HTTPS. The configuring of priority and server push needs to be done on the backend right now and cannot be controlled by the webdeveloper. This causes a tight coupling between front end and back end, which most people (including me) might not like.

All these optimalisations mean absolutely nothing, if your resources (html files, images, etc) are retrieved from many different servers.

Note: the effect of HTTP/2 is also that the old tips and tricks are not only useless, but can actually hamper the responsiveness of the website. An example of this is caching.

Angular 2

The speaker, Rachèl Heimbach, went quite fast through his presentation, which means we had time for two presentations in stead of one. On the other hand, it did require an inordinate amount of attention and knowledge of Angular/JavaScript/TypeScript to follow.

Angular 2 uses both ECMAScript 6 and TypeScript.

Some of the most important features⁶ of ECMAScript 6 that will return when you are attempting Angular 2:

class
import
export
private namespaces (without export and import, everything is by default off limits)
default values (used when parameters are omitted in the function call)
lambdas (no longer do we require the use of "var self = this;".

Benefits of using TypeScript in angular 2 are as follows:

safe typing, makes refactoring and debugging a whole lot easier
@Decorators, makes injection and adding behaviour generically a whole lot easier

Instead of the familiar services, factories and controllers of Angular 1, Angular 2 has simplified this a bit. Angular 2 basically consists of only Web components (that make up your pages/views/etc) and singleton injectors (that can take the place of your controllers, factories and services.) As you can see there is no longer a distinction necessary.

Some more enhancements:

ChangeDetection
ViewEncapsulation (with a shadow dom)
Provide function
ngUpgrade thing

It is possible to upgrade an Angular 1 application piece-by-piece or add Angular 2 components to it. The other way around is also possible.

Notes

HTTP/2 seems to be more and more widely supported. Angular 2 is still in the beta phase, however, it seems to be fairly stable. Unfortunately, it is currently not recommended for production use. However, the presentation did point out that in order to make the task of porting your application from Angular 1 to Angular 2 less onerous, it might be a good bet to start by designing the new parts of your Angular 1 application according to the Angular 2 style.

A question was raised on whether or not you should use Angular 2 at all. It seems Google will support Angular 1 for as long as there is a market for it. I heard that they measure the traffic to the two websites (Angular 1 and Angular 2) to determine interest. I got the impression from the presentation that Angular 1 has slowly been moving towards the new Angular 2 way of doing things.

Performance wise, Angular 2 is a step in the right direction. Keeping new Angular 2 in mind, whilst working on an Angular 1 application seems to be a very safe bet. If the need will arise in the future that a port is required, at least it will not be as herculean a task as first thought.

References

[1] Angular 2: https://angular.io/
[2] Quintor - Front end update: Angular 2.0 & HTTP/2: https://www.quintor.nl/sessie-front-end-update/
[3] Webpage testing: http://www.webpagetest.org
[4] Can I use?: http://www.caniuse.com
[5] Wikipedia - Above the fold: https://en.wikipedia.org/wiki/Above_the_fold
[6] ES6 Features: http://www.es6-features.org

Thursday, 22 October 2015

Running Glassfish on port 80

Well, in short. Linux does not allow non-root programs to listen/occupy ports below 1024. It is a security feature.

So what can I do to make a server that is non-root (because of security) able to receive/send messages through a privileged port? Luckily the question has already been asked multiple times on the Internet.

To summarize:

Run the program as root anyway
Have a root daemon run the program as root, then change the rootrights automatically to something less
Kernel param CAP_NET_BIND_SERVICE
Run a proxy server in front of it
Software that performs what you want
Port-forwarding using IPTables

For the matter of this blog, I am going to assume that I wish to make my Glassfish instance available via both port 80 (the default web port) and port 443 (the default ssl web port). For that is the use case I was faced with.

Run the program as root anyway

Well, that should work, but is a huge security risk in most cases.

We would just need to change the ports of the HTTP Listeners in Glassfish administration console. It can be found in the default-config option.

Have a root daemon run the program as root, then change the rootrights automatically to something less

This seems to be one of the functions of the inetd daemon.

Kernel param CAP_NET_BIND_SERVICE

sudo setcap cap_net_bind_service=ep some-binary

In Linux, the things root can do have been broken up into a set of capabilities. CAP_NET_BIND_SERVICE is the ability to bind to ports <= 1024.

Unfortunately, we would need to set the binary to "java". This automatically means that any java program will have the ability to access any ports. This is not what we want.

Run a proxy server in front of it

That's what I did initially. There are lots of web servers that are perfectly capable of redirecting traffic to another port. For example the Apache HTTP server and Nginx. I choose Nginx, as it seems to be quite easy to setup and doesn't come with a lot of extras, extras I do not need.

The excellent part of this solution is that we can use Nginx to serve static webpages/images/files and not bother the Glassfish with it.

Tricky is that I need the original originating IP address of the client, and that is lost without some magic configuration.

The bad part is that a proxy server is another link in the chain that needs to be supported and maintained etc.

Software that performs what you want

For example authbind seems mentioned a lot.

Port-forwarding using IPTables

This is the solution I went for eventually.

iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j REDIRECT --to-ports 8080

# Do the same thing for ssl:
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8181
iptables -t nat -A PREROUTING -p udp -m udp --dport 443 -j REDIRECT --to-ports 8181

Removing all the rules can be done with:

echo "Stopping firewall and allowing everyone..."

iptables -F

iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

To save the configuration, you can use iptables-save and iptables-restore. Or try something like:

]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

References

StackOverflow - Is there a way for non-root processes to bind to “privileged” ports (<1024) on Linux?: http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l#414258
Debian Administration - Running network services as a non-root user: http://www.debian-administration.org/article/386/Running_network_services_as_a_non-root_user
Ubuntu Help - Iptables HowTo: https://help.ubuntu.com/community/IptablesHowTo
Oracle Blogs - Byron's Pointless Ramblings - Run GlassFish V3 as a non-root Service on Linux Ubuntu/Debian: https://blogs.oracle.com/foo/entry/run_glassfish_v3_as_a
The JavaDude Weblog - Glassfish and https running secure applications: https://javadude.wordpress.com/2013/03/25/glassfish-and-https-running-secure-applications/