Re-negotiation error in Apache logs

After refactoring a site and implementing https for all pages on it, I started looking closely at the logs. I was getting lots of error messages with things like, ‘routines:SSL3_ACCEPT:unsafe legacy renegotiation’ and ‘Re-negotiation failed’, so I started looking into it. I was also vaguely aware of BEAST and RC4 weaknesses so I wanted to secure the Apache server as much as possible as well.

The first thing I found was a reference to the Mozilla Server Side TLS Config Generator. It gives a very long list of ciphers that are appropriate for your web server and client needs.

It also suggests using mod_headers to implement HSTS, which according to Wikipedia, “HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking.”

I didn’t see headers in my mods-available list and looking at the output of phpinfo();, it does not appear to have been implemented. To install mod_headers on Ubuntu you just need to run a simple command.


sudo a2enmod headers
sudo service apache2 restart

Now my mods look like this:
Apache mods

My old SSLCipherSuite was very short,
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!SSLv2:+EXP:+eNULL
The new one is a monster


SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

I have no idea what most of these are, but I’m sure the good folks at Mozilla do.

The last thing they recommend is that you implement OCSP Stapling. The details are complicated, but it basically speeds up the verification of the certificate.

After adding the new lines in the appropriate place in my sites-available file for the site, I restarted Apache and everything is running fine. In the fifteen minutes it took to write this up, I have had no negotiation messages in the error log.

Once you have implemented the changes, test your site at SSLabs. I got an A+.

Odd Thing About Symlinks

I refactored a site recently and rather than having a bunch of files with identical headers and footers, I created an index.php file with conditionals to create the meta data and then include the content. To preserve the existing file structure, I just created symlinks to the index.php file. So I did something like this:


ln -s index.php oldname1.php
ln -s index.php oldname2.php

This works great and is pretty easy to implement. (Yes there are other ways to do it.)

I ran into a problem when I tried to create symlinks in some subdirectories to prevent the “You don’t have permission to access /include.php/ on this server.” error message. I turns out that you have to be in the subdirectory where you want the alias to reside. This works:


cd Guides
ln -s ../manuals/index.php index.php

This does not:

cd manuals
ln -s index.php Guides/index.php

Getting the position of elements on the screen

I have a game where I move a target and drop it on foils. I know where I put the foils, but I wanted to know where they are in relation to the window if the window is scrolled or resized. This isn’t exactly what I was needing, but it’s useful enough that I might need it in the future. 


// Find the position of elements
function getOffset(element) {
    element = element.getBoundingClientRect();
  return {
    left: element.left + window.scrollX,
    right: element.right + window.scrollX,
    top: element.top + window.scrollY,
    bottom: element.bottom + window.scrollY
  }
}
function whereAreTheFoils() {
    // Find out where things are for initial setup and debugging
    var foil0 = document.getElementById('foil_0');
    var foil1 = document.getElementById('foil_1');
    var foil2 = document.getElementById('foil_2');
    var foil3 = document.getElementById('foil_3');
    console.log('Foil 0 is at LR ' + getOffset(foil0).left + ', ' + getOffset(foil0).right );
    console.log('Foil 0 is at TB ' + getOffset(foil0).top + ', ' + getOffset(foil0).bottom );

    console.log('Foil 1 is at ' + getOffset(foil1).left + ', ' + getOffset(foil1).top );
    console.log('Foil 2 is at ' + getOffset(foil2).left + ', ' + getOffset(foil2).top );
    console.log('Foil 3 is at ' + getOffset(foil3).left + ', ' + getOffset(foil3).top );
}

Redirecting missing links

I just updated a site so that it works better on phones and tablets. While updating I also cleaned up a lot of old code. In the process of cleaning up many of the old pages are no longer valid. Rather than redirecting to a generic page, I can redirect certain links to specific missing link pages. This is what I did for old manuals pages that I moved.


<?php
$oldurl = $_SERVER['REQUEST_URI'];
// Redirect requests for manuals
switch ($oldurl) {
  case '/products/mobile/manual_1.php';
  case '/products/mobile/manual_2.php';
  case '/products/mobile/manual_3.php';
  case '/products/mobile/manual_4.php';
  etc.

    header("Location: https://www.wellgolly.com/products/manuals_mobile.php",TRUE,301);
    break;
}
?>
<div  class="centered">
<h1>Error 404<br />Document not found</h1>
    <img class='pure-img-responsive centered' src='/images/sad.png' alt='Sad' />
    <p>We’re sorry, but the page you requested could not be found.<br />
    Please use the menus at the top or bottom of this page to find what you are looking for.</p>

</div>

By parsing the $oldurl, you can redirect missing files from sections of your site to a missing page that can help your visitors find what they are looking for rather than just a generic page.

Apache error.log Warning

I get a bunch of these warnings in my logs and wondered what they were.


Command line: '/usr/sbin/apache2'
Loading CGI at runtime.  You could increase shared memory between Apache processes by preloading it in your httpd.conf or handler.pl file

From a Mason mailing list it looks like it is caused when Mason is loaded each time it is needed rather than when Apache starts.
“may be a recommendation that comes from HTML::Mason::ApacheHandler2.”

I have one set of pages only site that use Mason so I’m not going to worry about it.