HTML5 preconnect

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.

Supported in:

  • Firefox 39+ (Firefox 41 for crossorigin)
  • Chrome 46+
  • Opera


<link rel="preconnect" href="//example.com" />
<link rel="preconnect" href="//cdn.example.com" crossorigin />

REFERENCES:

HTML5 DNS prefetch

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" />

Supported in:

  • MSIE9+ (MSIE10+ as dns-prefetch)/Edge
  • Firefox
  • Chrome
  • Safari
  • Opera

REFERENCES:

Domain-based Message Authentication, Reporting & Conformance (DMARC) Email

DMARC was published in 2012 to build upon the SPF and DKIM email conventions for authorizing senders. It allows specification of policies and provides for reporting of actions performed under those policies.

Assistant:
http://www.kitterman.com/dmarc/assistant.html

DNS Entry Resembles:

_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=none

Simple verification…. send an email to this address and you will receive a response with your SPF, DKIM and DMARC compliance status:
mailto:[email protected]eturnpath.net

REFERENCES:

Sender Policy Framework (SPF) Email

This is a simple mechanism, using DNS to certify that email from your domain comes from authorized servers. This is accomplished by adding a DNS record to identify the servers from which you send legitimate email. Emails sent from other servers MAY then be assumed as forged (SPAM) and blocked by the receiving email server.

NOTE: This can be easily spoofed, as such it should be a portion of your email security strategy, look into DKIM and DMARC too!

One thing that I initially did not understand… if you are supporting IPv6 and IPv4, you should merge your records onto a single DNS TXT entry:


example.com TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:x:xxx:xxxx:xxx:xxxx:xxxx:xxx -all

REFERENCES:

“msapplication-config” and browserconfig.xml

Windows-8/MSIE-11 introduced Tiles, as such server administrators may have started seeing HTTP 404 errors in their server logs as it attempts to look for a “browserconfig.xml” file at the root of a website domain. If you are inclined to use this file, you should definitely look into the documentation for how to best make use of it. Others may just wish to prevent the error from making “noise” in their log files.

To remove the error, add the following to your pages; alternately you COULD define the URL of your file as the ‘content’ attribute:

<meta name="msapplication-config" content="none" />

You can alternately place an empty /browserconfig.xml on your web server for each domain.

An common example of how to use this file is below:

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
<msapplication>
<tile>
<square70x70logo src="/mstile-70x70.png"/>
<square150x150logo src="/mstile-150x150.png"/>
<wide310x150logo src="/mstile-310x150.png"/>
<square310x310logo src="/mstile-310x310.png"/>
<TileColor>#8bc53f</TileColor>
<TileImage src="/mstile-150x150.png" />
</tile>
</msapplication>
</browserconfig>

REFERENCES:

clientaccesspolicy.xml

Similar to ‘crossdomain.xml’, Silverlight has some security features, this too is often noticeable by large number of HTTP 404 errors for a file named ‘clientaccesspolicy.xml’ in my webserver logs.

The most simple solution to the 404’s that restricts Silverlight is to add an empty file at the root of your websites.

REFERENCES:

Create self-signed SSL certificates for Apache on Ubuntu

To increase the security of your web applications, it is a standard process to enable HTTPS/SSL/TLS. Unfortunately, purchasing certificates can often be very expensive. Luckily, you can create a self-signed certificate for free for casual use or testing.

These steps are for Ubuntu, I wrote similar documentation for the Windows platform that you can find way back in my blog archives!

NOTE: As certificates generated in this manner are not verified by any recognized authority, many browsers will warn users (often in frightening language) about their insecurity. As stated above, these are best used only for internal use.

  1. First you will need to have apache2 installed, at a minimum you need to run:
    sudo apt-get install apache2
  2. Enable the SSL module:
    sudo a2enmod ssl

  3. Create the folder to store the keys and certificates:
    sudo mkdir /etc/apache2/ssl

  4. Generate a private key and certificate:

    sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

    Enter reasonable values for the fields in question.
    For FQDN Common Name enter *.domain.com for wildcard support!

  5. Edit the config file:

    sudo vi /etc/apache2/sites-available/default-ssl.conf

  6. Un-comment or update the following lines:

    ServerName YOURDOMAIN.COM
    ServerAlias WWW.YOURDOMAIN.COM
    SSLCertificateFile /etc/apache2/ssl/apache.crt
    SSLCertificateKeyFile /etc/apache2/ssl/apache.key

  7. Enable to SSL website and restart:

    sudo a2ensite default-ssl.conf
    sudo service apache2 reload
    sudo service apache2 restart

  8. Test it out… provided your firewall routes port 443 to your server.

    https://www.ssllabs.com/ssltest/analyze.html?d=YOURDOMAIN.COM

REFERENCES:

Name based virtual hosting with Apache2 on Ubuntu

I often find it necessary to setup a temporary server for testing web applications. The easiest way to support this is often to create an integration (beta) test server that can be configured to support multiple hosts.

Initial Installation:

sudo apt-get install apache2
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod rewrite
sudo chmod 755 /var/www

To add a new site:

cd /etc/apache2/sites-available
sudo cp 000-default.conf yourdomain.com.conf
sudo vi yourdomain.com.conf
(change values as appropriate)
sudo chown -R YOURUSER:YOURGROUP yourdomain.com.conf
sudo mkdir -p /var/www/yourdomain.com
sudo chmod 755 /var/www
sudo vi /var/www/yourdomain.com/index.html
(add some fluff)
sudo chown -R YOURUSER:YOURGROUP /var/www/yourdomain.com
sudo a2ensite yourdomain.com
sudo service apache2 reload
sudo service apache2 restart

NOTE: replace YOURUSER and YOURGROUP with appropriate values for your server.

Cross-Origin Resource Sharing (CORS) Header

Crossdomain access can be enabled in JavaScript with a mechanism similar to that in Flash. Instead of hosting a crossdomain.xml file though, crossdomain access is enabled per file, through an additional HTTP response header:

Access-Control-Allow-Origin: *

CORS is a more modern equivalent to JSONP for cross-domain XmlHttpRequests(AJAX) with options to limit domains, subdomains and ports.

Initial browser support:

  • Firefox 3.5
  • Chrome 4
  • Safari 3.2
  • MSIE 8

REFERENCES:

crossdomain.xml

Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

REFERENCES: