If you have already started using HSTS to force users to your HTTPS website, the use of ‘preload’ is another simple addition as it only requires the addition of the keyword to the header.
Once done, you can either wait for your site to be identified (which can take a long time, or forever for less popular websites) or ideally, submit your hostname to be added to the lists preloaded in many modern browsers. The advantage here is that your users will never make a single request to your HTTP website and will automatically be directed to HTTPS.
An HTTP Header example:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Apache2 configuration example:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
A relatively new HTTP Header that is supported by most modern browsers (except MSIE) is the “Referrer-Policy” header. There have been previous attempts to implement similar protections through use of the ‘rel’ (or ‘rev’) attributes on links to external websites. The latest approach takes a different approach and prevents leaking of internal URLs, and in some cases parameters, to external websites. This is important from a security perspective as you might maintain some sensitive information in your page urls, that would otherwise be inadvertently shared with an external website.
Clearly, you’ll need to determine your own level of security based upon your needs. Example: ‘no-referrer’ would be the most strict and would prevent the browser from sending the ‘Referer'(sic) header even to your own websites pages.
Example header values:
Implementation can be accomplished in many ways, the most simple being and addition to your HTTP server configuration similar to the one shown below for Apache 2.x:
Header always set Referrer-Policy strict-origin
If you are running a secure website, it’s a good idea to prevent non-secure assets from being included on your page. This can often happen through the use of content management system, or even through website vulnerabilities. A simple change in HTTP headers will help browsers to defend against them.
Most modern browsers, except MSIE, currently support this approach.
– Firefox 48+
As the web has been shifting to HTTPS for security and performance reasons, there are many methods to migrate users. One simple method is via the use of the Content-Security Header.
Most modern browsers, except MSIE, currently support this approach.
– Chrome 43+
Using a personal proxy server can be helpful for a variety of reasons, such as:
- Performance – network speed and bandwidth
- Security – filtering and monitoring
- Debugging – to trace activity
Here are some simple steps to get you started, obviously you will need to further “harden” security to make it production ready!
sudo apt-get install squid3
sudo mv squid.conf squid.orig
sudo vi squid.conf
NOTE: the following configuration works, but will likely need to be adapted for your specific usage.
auth_param digest program /usr/lib/squid3/digest_file_auth -c /etc/squid3/passwords
#auth_param digest program /usr/lib/squid3/digest_pw_auth -c /etc/squid3/passwords
auth_param digest realm proxy
auth_param basic credentialsttl 4 hours
acl authenticated proxy_auth REQUIRED
acl localnet src 10.0.0.0/8 # RFC 1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC 1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC 1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
#acl SSL_ports port 443
#http_access deny to_localhost
#http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow authenticated
Create the users and passwords:
sudo apt-get install apache2-utils (required for htdigest)
sudo htdigest -c /etc/squid3/passwords proxy user1
sudo htdigest /etc/squid3/passwords proxy user2
Open up firewall port (if enabled):
sudo ufw allow 3128
Restart the server and tail the logs:
sudo service squid3 restart
sudo tail -f /var/log/squid3/access.log
OTHER FILE LOCATIONS:
MONITORING with Splunk…
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/squid3/access.log -index main -sourcetype Squid3
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/squid3/cache.log -index main -sourcetype Squid3
Link prefetching is used to identify a resource that might be required by the next navigation, and that the user agent SHOULD fetch, such that the user agent can deliver a faster response once the resource is requested in the future.
<link rel="prefetch" href="http://www.example.com/images/sprite.png" />
<link rel="prefetch" href="/images/sprite.png" />
- MSIE 11+/Edge
- Firefox 3.5+ (for HTTPS)
In addition to dns-prefetch, you can take browser performance one step further by actually creating a new connection to a resource.
By initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, you allow the user agent to mask the high latency costs of establishing a connection.
- Firefox 39+ (Firefox 41 for crossorigin)
- Chrome 46+
<link rel="preconnect" href="//example.com" />
<link rel="preconnect" href="//cdn.example.com" crossorigin />
I often get into some fringe areas of micro-optimizations of website performance, DNS prefetching is another one of those topics.
To understand how this can help, you must first understand the underlying concepts that are used within the communications used to build your web page.
The first of these is a “DNS Lookup”, where the domain name (www.example.com) is converted into a numerical address, the IP address of the server that contains the file(s).
In many websites, content is included from other domains for performance or security purposes.
When the domain names are known in advance, this approach can save time on the connection as the lookup can fetched in advance, before it is required on the page to retrieve assets.
This can be particularly useful for users with slow connections, such as those on mobile browsers.
<link rel="dns-prefetch" href="//www.example.com" />
- MSIE9+ (MSIE10+ as dns-prefetch)/Edge
/* MOVED */
If you look at HTTP Headers as often as I do, you’ve likely noticed something different in Firefox 44 and Chrome 49. In addition to the usual ‘gzip’, ‘deflate’ and ‘sdhc’ , a new value ‘br’ has started to appear for HTTPS connections.
Compared to gzip, Brotli claims to have significantly better (26% smaller) compression density woth comparable decompression speed.
The smaller compressed size allows for better space utilization and faster page loads. We hope that this format will be supported by major browsers in the near future, as the smaller compressed size would give additional benefits to mobile users, such as lower data transfer fees and reduced battery use.
- Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.
- Brotli -11 density compared to gzip -9:
- html (multi-language corpus): 25 % savings
- js (alexa top 10k): 17 % savings
- minified js (alexa top 10k): 17 % savings
- css (alexa top 10k): 20 % savings
NOTE: Brotli is not currently supported Apache HTTPd server (as of 2016feb10), but will likely be added in an upcoming release.
Until there is native support, you can pre-compress files by following instructions here…