second place in the arms race

Posted by Dick on July 24, 2008

Came across this on my travels last night. 

filters out lusers for no extra charge

filters out lusers for no extra charge

Like your style, girl. Posted without further comment (it might give the game away).

adding existing SSL keypairs to Java keystores

Posted by Dick on June 26, 2007

I want my Roller install
to use LDAP authentication (instead of its own account database).
LDAP auth means cleartext passwords, so I need to run the site over SSL.

where glassfish keeps SSL certs and keys

Each Glassfish domain has it’s own keystore, which is protected by what the docs call the
‘admin master password’ (not the same as the ‘admin password’).

The master password is just a Java keystore password,
so if you didn’t say otherwise at domain creation time
it defaults to ‘changeit’.
You can check by trying to list the entries in your keystore:

goldfish $ keytool -list -keystore \
   /domains/rollerdisco/config/keystore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
s1as, Apr 22, 2007, PrivateKeyEntry,
Certificate fingerprint (MD5): 80:08:13:50:00:00:80:08:13:50:00:00

There’s just one entry – s1as – which is the SSL keypair for the domains admin webapp (om port 4848).

As of version 2, the Glassfish admin UI lets you choose keypairs from this keystore, but it can’t import into the keystore itself.
So you’ll have to break out the command line.

As you’ll see, I really hope they add that feature soon.

lots of swearing

If you’re creating a new keypair, things are relatively sane – see
Ryans howto .
I’m unlucky enough to have an existing apache-style’server.key/server.crt’ PEM keypair I want to use.

This turns out to be a massive pain in the arse. You’d think ‘keytool -import’ would do the trick,
but that only lets you add the certificate – keytool assumes it created the inital private key so doesn’t
provide a way to import one.

Googling found some very old tools for doing this, most of which only work with older, PKCS12 based keystores.

Let me save you an afternoon. The Jetty project have a tool called
PKCSImport
which is by far the least shitty way of doing this.

First, merge the two files using everyones favourite crypto swiss army knife:

goldfish $ openssl pkcs12 -export -out roller.p12 \
  -inkey roller.key -in roller.crt

It asks you for an export password. ‘foo’ works fine :)

Then get the Jetty jarfile and run the tool against your PKCS keypair:

goldfish # /usr/sfw/bin/wget http://kent.dl.sourceforge.net/sourceforge/jetty/jetty-6.1.4rc0.zip
goldfish # unzip jetty-6.1.4rc0.zip
goldfish # /j2ee/jdk/bin/java \
  -cp jetty-6.1.4rc0/lib/jetty-6.1.4rc0.jar \
  org.mortbay.jetty.security.PKCS12Import \
  roller.p12 /domains/rollerdisco/config/keystore.jks
Enter input keystore passphrase: foo
Enter output keystore passphrase: 
Alias 0: 1
Adding key for alias 1

This imports your certificate and keypair and creates a new keystore entry.
Unfortunately the entry is called ’1’, which is hardly self-documenting, so
I’ll rename that to the domain name it’ll run on:

goldfish # /j2ee/jdk/bin/keytool -changealias \
  -keystore /domains/rollerdisco/config/keystore.jks \
  -alias 1 -destalias roller.yourdomain.com

use the certificate

Glassfish already serves webapps over https, it’s just on a non-standard port of 8181
(the—domainproperties option to asadmin create-domain can specify this. Yay hindsight).

Go to the admin webapp, and browse to :

Configurations → server-config → HTTP Service → HTTP listeners

under there you’ll see 3 listeners

  • admin-listener runs the Admin Console you’re using (on https port 4848) so you probably want to leave that the hell alone
  • http-listener-1 (aka the ‘instance port’) defaults to 8080 . I set mine up on port 80 during my SMF setup .
  • http-listener-2 (is the https port), still on it’s default of port 8181

First change the http-listener-2 port from 8181 to 443, then click over to the SSL tab.

Enter the keystore alias name for the keypair you just imported in ‘Certificate Nickname:’ and tick the TLS and SSLv3 boxes.
Also select at least the ‘common ciphers’.

We’re now running the same webapp (roller) over both the http and https.
Finally, go back to http-listener-1 and set the SSL redirect port to 443 – this tells the webapp to redirect to SSL for
sensitive operations.

Alternatively, turn off the http listener (untick ‘Listener: enabled’) to ensure all traffic comes over https.

roam if you want to

Posted by Dick on April 06, 2006

UPDATE: I’ve gone off the idea. I don’t roam, I don’t want all the family to have to know the WPA passphrase to use their laptop account, and I like wmii , where applets don’t really make any sense. I prefer the system-wide way of doing WPA myself.

Here’s the Ubuntu Dapper (or better) ‘WPA Howto’:

$ sudo apt-get install network-manager wpasupplicant
$ # edit out the NICs in /etc/network/interfaces
$ # that you want to be managed by NM
$ sudo reboot
$ # after reboot, run up 'nm-applet'

NetworkManager is great. The daemon runs in the background, watching for HAL events, and uses the best connection it can.

Plug in ethernet, it uses ethernet. Yank it out, it scans for WLANs.

If it needs help (e.g. unlocking the WPA-PSK or WEP keys stored in your keyring) it asks the user via a GNOME or KDE applet2. It uses a local DNS forwarder and can notify apps (over DBUS) of network state changes.

This setup has a few implications. The most obvious is that you don’t get online until after you login to the GUI.
It also assumes the user is the one with the knowledge, not (whoever is root on) the laptop (suppose that’s how other OSes handle it anyway, just feels odd).

I imagine if you run many non-DBUSed servers that need a network at boot, or have hardcoded IPs in your firewall, it might piss you off a bit. But would you roam with that setup?

Although the applet is by default the font of all knowledge, you could easily run a non-GUI userland component as part of the usual boot If ubuntu-installer had one, WPA wireless users could net install at last.

1 seems 256Mb isn’t enough RAM (!) to hibernate. Shut down firefox first and it’s fine.

2 the applet works in fluxbox (and other window managers I presume) too, but it’ll ask you for the passphrase every boot. You can Google up some gnome-keyring voodoo if that drives you mad.

wpa for freebsd

Posted by Dick on January 23, 2006

Despite our ups and downs, for me there’s still
only one choice for a server OS .

Luckily, FreeBSD 6.x now has WPA supplicant in the base,
along with ipi/ipw (Centrino 802.11b/g support), and word is
the 5.x wrinkles are ironed out.

So I thought I’d do a BSD version of the
WPA howto
I wrote the other day.

0: ingredients:

  • FreeBSD 6.0
  • a WPA capable supported wireless NIC (mainly 802.11g kit). I’m using a Cardbus NEC WL54AG - piece of crap but supported by ath and only 20 notes on ebay. Replace ath0 with ipw/ipi/ndis as appropriate.
  • a computer
  • an access point (should work on ad-hoc WLANs, too)
  • a rootprompt

1: patch your kernel

Sod’s law -
since we’re securing our WLAN you might as well do it right.

2: get your modules on

If your card doesn’t show up in ’ifconfig -a’, check dmesg. Mine said:

cardbus0:  at device 0.0 (no driver attached)

until I kldload if_ath, then I got:

ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
ath0:  mem 0x88000000-0x8800ffff irq 12 at device 0.0 on cardbus0
ath0: Ethernet address: 00:0d:00:1d:41:1b
ath0: mac 5.9 phy 4.3 radio 3.6

3: setup /etc/wpa_supplicant.conf

If you’re accessing a pre-shared key WPA network, you should only need
to tweak the ‘psk=’, ‘proto=’ lines.

For anything else, read the (excellent)
wpa_supplicant.conf
manpage.

 # used by wpa_cli(8) (see 'troubleshooting' below)
 ctrl_interface=/var/run/wpa_supplicant
 ctrl_interface_group=0

 # boilerplate, essentially. see the example for a walkthrough
 eapol_version=1
 ap_scan=1
 fast_reauth=1

 # 'network' is a group of APs sharing a SSID
 network={
         ssid="YOURSSID"
         # 'RSN' == 'WPA2'
         proto=RSN WPA
         # that's 'pre-shared key'
         key_mgmt=WPA-PSK
         # lists ciphers to try. CCMP is AES
         # pairwise is for client <-> AP traffic, group is for broadcasts
         pairwise=CCMP TKIP
         group=CCMP TKIP
         psk="hail beastie, baby"
 }

4: setup your AP

(the faint-hearted should probably check they have ethernet access to it first)

You want to enable WPA-PSK and broadcast your SSID. On the WRT54G that goes:

  • under ‘wireless’ → ‘basic wireless settings’
    • enable “SSID broadcast” (no need for security by obscurity)
  • under ‘wireless’ → ‘wireless security’
    • set ‘security mode’ = ‘WPA2 personal’ (’enterprise’ needs a RADIUS server)
    • WPA algorithms = ‘AES’ or ‘TKIP + AES’ (I went for plain AES)
    • shared key = choose a long passphrase (it’s not like you’ll type it much)

Check you have everything you need (before you lose connectivity) and ‘save settings’.

5: gentlemen, start your NICs

As root, try this:

/etc/rc.d/wpa_supplicant forcestart ath0
/sbin/dhclient ath0 # or just 'ifconfig ath0 .....'

and hopefully you’re back online.

Since I told my supplicant to try CCMP, then TKIP (the ’pairwise=…’ .conf line),
I was asked to kldload
wlan_ccmp
and restart the supplicant. If it fell through to TKIP it presumably want
wlan_tkip
.

6: automatic for the people

Assuming our /etc/wpa_supplicant.conf was good, we now want this
to start at boot.

First the loader has to pull in our modules. For my case, that’s

 cat >> /boot/loader.conf
 if_ath_load="YES"
 wlan_ccmp_load="YES"
 wlan_tkip_load="YES"# can't hurt
 EOF

Now you just flag the interface as using WPA and DHCP:

 cat >> /etc/rc.conf
 ifconfig_ath0="WPA DHCP"
 EOF

7: troubleshooting

wpa_supplicant will give you more detail than you could possibly want if you pass it
a ’-dd’ argument. A ’ps awwux|grep supplicant’ should give you the full command you’re
using, just add ’-dd’ to those arguments.

That should give you some idea where it’s failing, or at least get you a string to google for.

I also highly recommend
wpa_cli
for those who a) don’t want to hardcode a PSK in a cfg file, b) need to debug their connection or c) like talking to network processes for some reason.

8: homework schools out

Laptop users might want to play with devd and have the start_if.ath0 script run when you insert your NIC should be pleased to find you can now just plug in your card and devd will fire it up correctly for you. It even kills off wpa_supplicant and dhclient neatly when you eject the card.

fun with wpa_supplicant

Posted by Dick on November 21, 2005

Here’s how I got an 11Mbit Centrino (ipw2100) to work with WPA2.
This should apply to 54Mbit cards too (e.g. for Atheros, use ‘madwifi’ for the driver and ‘ath0’ for the interface).

before you read on

If you’re on Feisty (Ubuntu 7.04) or better, network manager is now in the base and can handle WPA for you. It interferes with the config below, so choose 1 howto and stick to that.

Personally I don’t need roaming and I like setting up the passphrase laptop-wise (so my kids don’t need to know it), so I’ve come to prefer this way.

WPA and Centrino

I always thought WPA was 802.11g only and 11Mb peasants were stuck with WEP.
Turns out that’s not the case -
11Mbit access points are older, so usually only support WEP, but some 11Mb cards just need a firmware bump.

Other reasons for solidarity with my 802.11b brothers:

  • found out pensioners in my street run WLANs (when d-i insisted my SSID was ‘NETGEAR’) – I need some sort of security pronto and WEP isn’t worth having
  • the 54Mbit NIC I have is a big, grey, ugly PCCARD thing – my 11mb is builtin
  • NTL lied. The ‘free’ 10Mbit upgrade costs an extra tenner a month, so I’m sticking with a 4Mb link. 802.11g wouldn’t make the Net any faster.
  • there are no servers on the WLAN now – I don’t really need 802.11g bandwidth

I’m not even supposed to be here today

I don’t pretend to fully understand WPA, but this is works nicely for me and is quick to do.
I was ‘getting round to’ IPSEC for 4 years (while Granny Jenkins at no. 25 leeched my bandwidth on Kazaa, probably). ‘Better’ security isn’t, if it’s too hard to setup.

Besides, I’m fed up of HOWTOs that run ‘WEP is a worthless piece of crap. You should use IPSEC or something. Anyway, here’s how to use WEP.’

I’m sure your eyes are glazing over by now, so let’s get on with it.

kit

I used:

  • a Linksys WRT54G access point
    • cheap, runs ‘teh linuks’ and supports WPA2. Skill.
  • Ubuntu (Breezy Badger or better)
    • me and Debian had words. No, I don’t want to talk about it
  • Intel Pro Wireless 2100 wireless NIC (Centrino)
    • non-free driver, but ubuntu sees it out of the box
  • some other way of talking to your AP
    • for when this howto ruins your wireless link

setup the AP

Enable SSID broadcast and WPA shared key auth. On the WRT54G that goes:

  • under ‘wireless’ → ‘basic wireless settings’
    • enable ‘SSID broadcast’ ( simplifies the client end. Not that big a deal )
  • under ‘wireless’ → ‘wireless security’
    • security mode = WPA2 personal (shared key deal like WEP, only without the shit crypto. ‘enterprise’ needs a RADIUS server. I’m not going there)
    • WPA algorithms = ‘AES’ or ‘TKIP + AES’ ( the letters ‘AES’ give me a fuzzy glow, so I skipped TKIP )
    • shared key = “a long passphrase , it’s not like you’ll type it often” (seriously, don’t skimp on this.)

Non-WPA authed clients (i.e. you) will be ‘unplugged’ when you click ‘save settings’.

the client end

Meet wpa\supplicant
- a daemon that will speak WPA to the AP for us
(it means : ‘one who begs for mercy’ – I don’t know if that’s supposed to be a joke or not).
In Breezy, you’ll need to enable the ‘universe’ sources to get it.

The config file, /etc/wpa_supplicant.conf, holds WLAN definitions. wpa_supplicant will try
each in turn until it finds a match. I don’t know about you, but I just have the one WLAN at the moment.

The best advice in this whole post is: skim through the examples (they should be in /usr/share/doc/wpasupplicant/examples/wpa_supplicant.conf.gz, that path might vary). I wasted hours on google before resorting to reading that file, and it’s probably all you’ll need.

For the settings above, mine goes:


# see wpa_cli stuff below
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0

# boilerplate, essentially. see the example for a walkthrough
eapol_version=1
ap_scan=1
fast_reauth=1

# 'network' is a group of APs sharing a SSID
network={
        ssid="YOURSSID"
        # 'RSN' == 'WPA2'
        proto=RSN WPA
        # that's 'pre-shared key'
        key_mgmt=WPA-PSK
        # lists ciphers to try. CCMP is AES
        # pairwise is for client -> AP, group is for broadcasts
        pairwise=CCMP TKIP
        group=CCMP TKIP
        # this can be made faster.see wpa_passphrase(1)
        psk="maybe your christmas list?"
}

now ‘simply’ run wpa_supplicant

First reset the interface


 $ sudo ifconfig eth1 down
 $ sudo killall dhclient
 $ sudo ifconfig eth1 up 0.0.0.0

then try running the supplicant in the foreground with max debugging (-dd)


 $ sudo wpa_supplicant -Dipw -ieth1 -dd -c/etc/wpa_supplicant.conf

-Ddrivername, (despite what the manpage says) is ESSENTIAL: without it, wpa_supplicant
will pick one, and in my experience it’s crap at guessing.

If you see lots of ’ioctl[PRISM2_IOCTL_HOSTAPD]: Operation not supported’ errors,
try a few drivers – see wpa_supplicant -h for a list.

Once I told it to use the IPW driver, I got one error


ioctl[SIOCSIWPMKSA]: Operation not supported
SIOCGIWRANGE: too old (short) data - assuming WPA is not supported

(the card can’t do WPA itself, so the supplicant takes care of it for us)
Then:


EAPOL: SUPP_PAE entering state AUTHENTICATING
EAPOL: SUPP_BE entering state SUCCESS
EAPOL: SUPP_PAE entering state AUTHENTICATED
EAPOL: SUPP_BE entering state IDLE

Now the WLAN is up (the equivalent of having ethernet plugged in).
Just run ‘dhclient eth1’ or configure IP by hand.

making it stick

edit /etc/default/wpasupplicant to say:


# /etc/default/wpasupplicant
# WARNING! Make sure you have a configuration file!
ENABLED=1
#  -w                   Wait for interface to come up
OPTIONS="-w -Dipw -ieth1 -c /etc/wpa_supplicant.conf"

Even with the ’-w’ flag, recent Breezys seem to start dhclient too soon. To fix this, edit the /etc/network/interfaces entry for your wireless NIC so it looks like:

 iface eth1 inet dhcp
    pre-up /etc/init.d/wpasupplicant start
    pre-up sleep 5
    post-down killall -q wpa_supplicant

this is the last song I will ever sing

Your security now rests in that shared secret, and it’s brute forcable,
so make sure it’s long, and that you change it regularly.

One last tip for debugging – wpa_cli(1) is a shell to talk to a running
supplicant. Handy for tweaking without constantly bouncing
the daemon, and it can even update your config file for you.


rasputnik@lumpfish:~$ sudo wpa_cli
wpa_cli v0.4.5
...some license stuff here...
Selected interface 'eth1'

Interactive mode

> status
bssid=<mac of the ap you are talking to>
ssid=YOURSSIDHOPEFULLY
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=your.ip.addr.ess
Supplicant PAE state=AUTHENTICATED
suppPortStatus=Authorized
EAP state=SUCCESS
> quit

Please let me know if I made any major mistakes (either comment or mail me, my username is ‘rasputnik’ and I have a GMail account) .