With POODLE the time has come to disable SSLv3 everywhere. There will be clients that break and need fixing but it needs doing. You can read more details and background on the vulnerability.

Here’s a few useful snippets from my experience with it this week:

Apache

Make sure the combination you have for the SSLProtocol line disables SSLv2 and v3 - something like: SSLProtocol All -SSLv2 -SSLv3

DataPower

Ensure your crypto profiles have SSLv2 and v3 disabled in the options line:

[code lang=text] switch co crypto profile option-string OpenSSL-default+Disable-SSLv2+Disable-SSLv3 exit exit write mem [/code]

Java

If you have problems with handshakes from Java client process force the protocols to use with -Dhttps.protocols=TLSv1

nginx

Make sure the ssl_protocols line in your SSL configuration doesn’t have SSLv3 in it. ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

nodejs

Make sure you don’t have secureProtocol:SSLv3_method anywhere in https options - use TLSv1_method instead if it’s really needed.

Websphere

See Security bulletin

Using my Raspberry Pi, Piglow and the traffic API feeds I have created a script to give me a visual representation of the journey time to work. This gives me an idea of the traffic before I leave the house in the morning, or so that when I’m working at home I can look at it and see how glad I am that I’m not sitting in traffic on the way to work :)

https://github.com/rickymoorhouse/trafficpi

1. Boot from Live CD / USB

2. Decrypt the filesystem

<code class="markdown">cryptsetup luksOpen /dev/sda5 <span class="emphasis">*hostname*</span>
</code>

3. Mount filesystems

<code class="sql">mount /dev/dm-2 /mnt
mount /dev/dm-3 /mnt/home
mount /dev/sda1 /mnt/boot
mount <span class="comment">--bind /dev /mnt/dev</span>
mount <span class="comment">--bind /sys /mnt/sys</span>
mount <span class="comment">--bind /proc /mnt/proc</span>
</code>

4. Enter chroot chroot /mnt

/etc/crypttab should have: sda5_crypt UUID=sda5_uuid

After experimenting a bit with MySQL locking today, I thought I’d make a note of what I’d discovered:

To create a lock, you need to use:

<code>LOCK TABLES table1 [READ |WRITE], table2 [READ |WRITE]</code>

READ is used to stop other people changing the table while you read from it. WRITE is used to stop other people reading the table while you write to it.

Once you have issued a LOCK TABLES statement, you will not have access to any tables you didn’t include.

When you have finished, you can issue the UNLOCK TABLES command.

The lock remains until you issue the UNLOCK TABLES command, your session ends, you start a transaction or your client is disconnected.

The MySQL locking mechanism is no use if you need to lock something between PHP requests, unless you have a separate process running persistently to maintain the connection to the database.

If you find that after rebooting your MySQL slave it stops replicating with the master and you see the “Failed to open the relay log” error in the logs it is probably caused by MySQL putting it’s relay logs in /var/run by default, which gets cleared out on boot.

To fix this, you need to change the location MySQL uses for the logging by adding the following line to the [mysqld] section of /etc/my.cnf

relay-log = /var/lib/mysql/relay-bin

Then edit /var/lib/mysql/relay-log.info to point to the first new relay log (leaving the master information the same.

/var/lib/mysql/relay-bin.000001 1 mysql-bin.12345 123456789

Then from the mysql prompt start the slave:

mysql> START SLAVE;

(Source: Arjen’s Journal)