Feeds:
Posts
Comments

New blog site

I’ve decided to run my own WordPress install, so head on over to arcticdog.com to carry on following me.

Xerox Colorqube Secure Print

The Windows driver for the Xerox Colorqube 9201 gives you option of a “secure print”, whereby the printer holds your job until you actually go up to the machine and type in a 4 digit PIN code. This means that you can be sure that you are at the printer when your job prints, so it doesn’t go missing. However, installing the Xerox supplied PPD file under CUPS for Linux, doesn’t provide that option. After some playing around, I came up with the following addition to the PPD to (sort of) add the facility:

(insert after the *JCLCloseUI: *JCLBanner line and before the *% Generic Accounting line)…

*% Secure Print

*JCLOpenUI *JCLSecure/Secure Print: Boolean
*OrderDependency: 10.0 JCLSetup *JCLSecure
*DefaultJCLSecure: False
*JCLSecure False/Off: ""
*JCLSecure True/On: "@PJL COMMENT OID_ATT_JOB_TYPE OID_VAL_JOB_TYPE_SECURE_PRINT;<0A>@PJL COMMENT OID_ATT_JOB_PASSWORD "AYWQ";<0A>"
*JCLCloseUI: *JCLSecure

This should now give you a “Secure Print” tick box on your Advanced tab of your print dialogue.

The AYWQ is the encrypted PIN. I’ve no idea what the encryption method is, I obtained it by capturing a print job sent with the Windows driver. In this case the PIN is 1234. I can’t see any method of being able to choose your own PIN at print time (unless anyone else has any ideas?) so its not terribly secure obviously, but its better than nothing – you’ll at least know that someone has printed and walked off with your job!

BEAST, OpenSSL and Apache

One of our servers was failing PCI compliance due to the BEAST vulnerability CVE-2011-3389.

I’d taken all the recommended steps for fixing:

Now, OpenSSL 0.9.6d introduced a countermeasure for the BEAST attack.
And yet, still we were failing. The key part of the fail message is this:

“If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable. OpenSSL uses empty fragments as a countermeasure unless the ‘SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS’ option is specified when OpenSSL is initialized.”

OpenSSL has initialisation option “SSL_OP_ALL” which can be used to
enable various bug workarounds that “should be rather harmless”. Problem
is, one of these workarounds is to disable the countermeasure, and it seems
that mod_ssl does indeed use “SSL_OP_ALL

As I see it, in order to pass PCI compliance (other than only allowing the rather weak RC4 cipher, or switching to GnuTLS) you have to hack the code. The wonders of open source.

You have two options, Do one of the following:

  1. Change OpenSSL (this assumes v1.0.1c)
    This has the side effect of making sure the countermeasure is enabled in any further apps you compile.

    Edit include/openssl/ssl.h and change:
      #define SSL_OP_ALL 0x80000BFFL
    to:
      #define SSL_OP_ALL 0x800003FFL

    Then recompile OpenSSL (not sure its necessary, but to be safe), and then recompile mod_ssl. Restart apache.

  2. Change Apache

    Edit modules/ssl/ssl_engine_init.c and change (around line 486):
      SSL_CTX_set_options(ctx, SSL_OP_ALL);
    to:
      SSL_CTX_set_options(ctx, SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);

    Recompile mod_ssl. Restart apache.

Home of the flat-packed husky

The idea of this site is to collect all my various random pieces of information in one place. It’s not really intended to be a blog as I don’t have that much to say 🙂