September 13, 2009 -
Tested under Debian Lenny
BUILDING AND INSTALLING FREERADIUS WITH TLS SUPPORT
Install the necessary packages :
apt-get install dpkg-dev fakeroot
Download the source :
cd /root
mkdir freeradius-tls
cd freeradius-tls
apt-get source freeradius
Make the changes :
Edit /root/freeradius-tls/debian/rules :
and change
--with
by
--without
for eap_tls, eap_ttls, eap_peap and openssl
Just as :
--with-rlm_eap_tls \
--with-rlm_eap_ttls \
--with-rlm_eap_peap \
--without-rlm_eap_tnc \
--without-rlm_otp \
--with-rlm_sql_postgresql_lib_dir=`pg_config --libdir`\
--with-rlm_sql_postgresql_include_dir=`pg_config --includedir` \
--with-openssl \
--without-rlm_eap_ikev2 \
--without-rlm_sql_oracle \
--without-rlm_sql_unixodbc \
Then, comment the following :
for pkg in ${pkgs} ; do \
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then \
echo "$$pkg links to openssl" ;\
exit 1 ;\
fi ;\
done
Edit /root/freeradius-tls/debian/control :
On the line beginning by “Build-Depends”
Add the folowing :
", libssl-dev"
at the end of the line (without the quotes)
Install dev libraries :
apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev
Build freeradius :
dpkg-buildpackage -rfakeroot
Building will end by a warning message, this is not important.
Put the packages on hold to avoid upgrading with a non-TLS version of FreeRADIUS :
echo “freeradius hold” | dpkg --set-selections
echo "libfreeradius2 hold" | dpkg --set-selections
echo "freeradius-common hold" | dpkg --set-selections
Install the packages we’ve just built :
dpkg --install freeradius-common_2.0.4+dfsg-6_all.deb libfreeradius2_2.0.4+dfsg-6_i386.deb
CERTIFICATES
Creating the CA
apt-get install openssl
Edit /etc/ssl/openssl.cnf
[ CA_default ]
dir = ./PKI
Edit /usr/lib/ssl/misc/CA.sh
CATOP=./PKI
Then type :
cd /etc/ssl
/usr/lib/ssl/misc/CA.sh -newca
Set a challenge password and a passphrase. This is needed.
The CA created will be copied to the server and clients later on.
Optional : if you have Windows XP clients
Create /etc/openssl/PKI/xpextensions
[xpclient_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.2
[xpserver_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.1
Server certificate signing request :
cd /etc/ssl
openssl req -new -nodes -keyout PKI/server_key.pem -out PKI/server_req.pem -days 730 -config openssl.cnf
Set a challenge password
Sign the server certificate request (if winxp clients) :
cd /etc/ssl
openssl ca -config openssl.cnf -policy policy_anything -out PKI/server_cert.pem -extensions xpserver_ext -extfile PKI/xpextensions -infiles PKI/server_req.pem
Mac clients :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/server_cert.pem -infiles PKI/server_req.pem
Then :
cp server_cert.pem server_cert.pem-backup
Edit server_cert.pem
Remove everything before the line —–BEGIN CERTIFICATE—– (this is needed for winxp clients)
Next :
cat server_key.pem server_cert.pem > server_keycert.pem
Create a client certificate signing request :
cd /etc/ssl
openssl req -new -keyout PKI/client_key.pem -out PKI/client_req.pem -days 730 -config openssl.cnf
Sign client cert request :
cd /etc/ssl
Windows xp client :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/client_cert.pem -extensions xpclient_ext -extfile PKI/xpextensions -infiles PKI/client_req.pem
Mac OS X client :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/client_cert.pem -infiles PKI/client_req.pem
Export P12 certs (Windows and Mac clients ) :
openssl pkcs12 -export -in client_cert.pem -inkey client_key.pem -out client_cert.p12 -clcerts
FREERADIUS CONFIG
FreeRadius
Do :
cp /etc/ssl/PKI/cacert.pem /etc/freeradius/certs/cacert.pem
cp /etc/ssl/PKI/server_keycert.pem /etc/freeradius/certs/server_keycert.pem
Then :
cd /etc/freeradius/certs
openssl dhparam -check -text -5 512 -out dh
dd if=/dev/urandom of=random count=2
chown freerad dh
chmod o-w dh
Next :
cp /etc/freeradius/eap.conf /etc/freeradius/eap.conf-default
/etc/freeradius/eap.conf :
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
tls {
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = whatever
private_key_file = ${certdir}/server_keycert.pem
certificate_file = ${certdir}/server_keycert.pem
CA_file = ${cadir}/cacert.pem
dh_file = ${certdir}/dh
random_file = ${certdir}/random
fragment_size = 1024
include_length = yes
check_cert_cn = %{User-Name}
cipher_list = "DEFAULT"
}
}
Edit /etc/freeradius/clients.conf
We will consider the access-point that will authenticate users against the RADIUS server has the IP 192.168.7.45 :
client localhost {
ipaddr = 127.0.0.1
secret = testing123
require_message_authenticator = no
nastype = other # localhost isn't usually a NAS...
}
client 192.168.7.45 {
secret = suchasecurepassword
shortname = linksys
}
Start FreeRADIUS :
freeradius -X -f
Set up wifi access point for authentication against our new RADIUS server
It depends on your hardware here.
You must usually go under the security panel of your device, where you can specify the IP/hostname and port of the RADIUS server, and the password (in our example : suchasecurepassword)
Configure clients
This will be the subject of a separate post as I will try to publish the method for all majors OSes (Linux, Mac and Windows) but don’t have much time for now.
Stay tuned !
This post is a stripped down version of the following howto by my colleague Jérôme :
http://hanoteau.blogspot.com/2009/03/howto-setup-eap-tls-wpa-network-with.html
July 23, 2008 -
I use SSH local port forwarding on a daily basis but I rarely use remote port forwarding. Today I forgot about the GatewayPorts option again, so I decided to write a quick post about SSH port forwarding.
Local port forwarding
Accessing a service (in this example SSH port tcp/22, but it could be anything like a web server on tcp/80) on a machine at work (172.16.10.10) from your machine at home (192.168.10.10), simply by connecting to the server work.example.org at work :
home$ ssh user@work.example.org -L 10000:172.16.10.10:22
We see the service is available on the loopback interface only, listening on port tcp/10000 :
home$ netstat -tunelp | grep 10000
tcp 0 0 127.0.0.1:10000 0.0.0.0:* LISTEN 1000 71679 12468/ssh
From your home machine, you should be able to connect to the machine at work :
home$ ssh root@localhost -p 10000
Local port forward for anyone at home !
If you want other people on your home subnet to be able to reach the machine at work by SSH, add the option -g :
home$ ssh user@work.example.org -L 10000:172.16.10.10:22 -g
We now see the service is available on all interfaces on your home computer, available for anyone to connect to on the local subnet :
home$ netstat -tunelp | grep 10000
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 1000 72265 12543/ssh
Anyone on your local subnet should be able to connect to the machine at work by doing this :
anyone$ ssh root@192.168.10.10 -p 10000
Remote port forwarding
Giving access to a service (SSH port tcp/22) on your home machine (192.168.10.10) to people at work
home$ ssh user@work.example.org -R 10000:192.168.1.10:22
We see on our server at work (on the loopback interface on port tcp/10000) that we have access to our SSH server at home :
work.example.org$ netstat -tunelp | grep 10000
tcp 0 0 127.0.0.1:10000 0.0.0.0:* LISTEN 0 73719534 3809/1
People logged in on the machine work.example.org now should be able to SSH into your home machine by doing :
work.example.org$ ssh user@localhost -p 10000
Remote port forwarding for anyone at work !
If you want everybody on the subnet at work to be able to SSH into your home machine, there’s no -g option for remote forward, so you need to change the SSH configuration of work.example.org, add to sshd_config :
GatewayPorts yes
Connect just as before :
home$ ssh user@work.example.org -R 10000:192.168.1.10:22
Now, it’s listening on all interfaces on the server at work :
work.example.org$ netstat -tunelp | grep 10000
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 0 73721060 4426/1
Anyone at work can now connect to your home machine by SSH via the server :
anyone.example.org$ ssh anyone@work.example.org -p 10000
Notes
- You would need to log in as root if you want services to listen on a port < 1024.
- Don't forget to open necessary ports on any firewall either at home or work.
- Unfortunately you can only forward services running on TCP, but there's a way to forward UDP through SSH using netcat http://www.wains.be/index.php/2007/02/13/tunneling-udp-requests-through-ssh/
July 18, 2008 -
I’m really into OpenVPN these days, see my two previous posts about it :
Setting up OpenVPN for your road warriors :
http://www.wains.be/index.php/2008/07/15/a-vpn-for-remote-users-with-openvpn/
Setting up a VPN between two sites :
http://www.wains.be/index.php/2008/06/07/routed-openvpn-between-two-subnets-behind-nat-gateways/
Today : how to route all traffic through the OpenVPN tunnel
On the server side :
First of all, if you want to route all your traffic through the VPN tunnel, you need to turn on IP forwarding (also called routing) and add a masquerading rule on the server (where eth0 is the device connecting you to the internet) :
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.30.0.0/24 -o eth0 -j MASQUERADE
To make routing persistent, see http://www.wains.be/index.php/2006/06/06/enable-ip-forward-under-rhelcentos/
Then, here’s the OpenVPN configuration :
port 10000
proto udp
dev tun
comp-lzo
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
duplicate-cn
server 10.30.0.0 255.255.255.0
client-to-client
push "dhcp-option DOMAIN local.example.org"
push "dhcp-option DNS 172.16.7.253"
push "redirect-gateway def1"
keepalive 10 120
persist-key
persist-tun
user nobody
group nogroup
log vpn.log
verb 1
chroot /tmp
You can see the option redirect-gateway that is responsible for creating all the routes on the client computer when the connection is set up.
The two other push options are only taken into account by Windows clients (to my knowledge).
If you want to change the DNS resolution of your linux clients, you need to use the up and down options on the client (see below).
Client configuration :
vpn.conf :
client
dev tun
proto udp
remote vpn.example.org
port 10000
nobind
persist-key
persist-tun
ca ./ca.crt
cert ./user.crt
key ./user.key
verb 5
up ./up.sh
down ./down.sh
ping 60
ping-restart 120
up.sh :
#!/bin/sh
mv /etc/resolv.conf /etc/resolv.conf.bak
echo "search local.example.org" > /etc/resolv.conf
echo "nameserver 172.16.7.253" >> /etc/resolv.conf
down.sh :
#!/bin/sh
mv /etc/resolv.conf.bak /etc/resolv.conf
When connecting to the server (with verbose option set to 5), we can see the server pushing the route settings to the client.
Fri Jul 18 23:22:19 2008 us=838005 ifconfig tun0 10.30.0.6 pointopoint 10.30.0.5 mtu 1500
Fri Jul 18 23:22:19 2008 us=843211 route add -net 72.x.x.x netmask 255.255.255.255 gw 172.16.7.253
Fri Jul 18 23:22:19 2008 us=845178 route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.30.0.5
Fri Jul 18 23:22:19 2008 us=848568 route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.30.0.5
Fri Jul 18 23:22:19 2008 us=850460 route add -net 10.30.0.0 netmask 255.255.255.0 gw 10.30.0.5
On the client, the routes :
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
72.x.x.x 172.16.7.253 255.255.255.255 UGH 0 0 0 wlan0
10.30.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.16.7.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.30.0.0 10.30.0.5 255.255.255.0 UG 0 0 0 tun0
0.0.0.0 10.30.0.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.30.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 172.16.7.253 0.0.0.0 UG 0 0 0 wlan0
June 7, 2008 -
Edit : between two or MORE subnets. Check out the exchange between Michael Antal and me in the comments. He’s been able to interconnect 3 subnets using this method and some slight tweaks in routes.
The following is the configuration needed to create a routed OpenVPN network between two remote subnets, both behind NAT gateways. On each side, the gateways will act as the VPN gateways.
Network subnets on both side must be different. In this example, we connect 192.168.1.0/24 to 192.168.200.0/24.
With this setup, we don’t even need to open ports at the NAT level on either side of the VPN.
Network configuration
Network A :
Subnet : 192.168.1.0/24
Gateway for Network A
VPN interface (tun0) : 10.0.0.1
Eth0 : 192.168.1.254
Eth1 / Public IP : 212.x.x.x (machineA.example.org)
Network B :
Subnet : 192.168.200.0/24
Gateway for Network B
VPN interface (tun0) : 10.0.0.2
Eth0 / Public IP : 66.x.x.x (machineB.example.org)
Eth1 : 192.168.200.254
If we imagine forwarding is rejected at the firewall level on machine B, we would need to allow traffic between the tun device created by OpenVPN and the LAN interface, as root you would then type :
iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
Make sure the rules remain applied across reboots (using iptables-save or storing the rules in /etc/rc.local or else)
Enabling IP routing :
We need to enable routing on both VPN gateways..
echo “1″ > /proc/sys/net/ipv4/ip_forward
Using this method, routing is not persistent across reboots, check the following link :
http://www.wains.be/index.php/2006/06/06/enable-ip-forward-under-rhelcentos/ (which works for Debian as well)
Static key generation :
We will use simple static key for our example…
openvpn --genkey --secret /etc/openvpn/vpn.key
Share the key between the VPN gateways over a secure channel (scp, etc.).
If you want to use certificates instead (which I recommend), check out : http://www.wains.be/index.php/2008/07/15/a-vpn-for-remote-users-with-openvpn/
OpenVPN configuration :
machine A : /etc/openvpn/vpn.conf
remote machineB.example.org
float
port 8000
dev tun
ifconfig 10.0.0.1 10.0.0.2
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
secret /etc/openvpn/vpn.key
route 192.168.200.0 255.255.255.0
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1
machine B : /etc/openvpn/vpn.conf
remote machineA.example.org
float
port 8000
dev tun
ifconfig 10.0.0.2 10.0.0.1
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
secret /etc/openvpn/vpn.key
route 192.168.1.0 255.255.255.0
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1
Establishing the connection :
On machine A type :
openvpn --config /etc/openvpn/vpn.conf
Machine A will try to establish the connection. Type the same command on machine B to initialize the connection.
As soon as the connection is up, hosts on network A should be able to ping hosts on network B and vice-versa. If you can’t ping from one side to the other, it’s probably a routing issue.
We can use traceroute from a machine on network A to see the path taken to reach a host on network B :
$ traceroute 192.168.200.30
traceroute to 192.168.200.30 (192.168.200.30), 30 hops max, 40 byte packets
1 192.168.1.254 (192.168.1.254) 2.128 ms 2.378 ms 2.781 ms
2 10.0.0.2 (10.0.0.2) 132.761 ms 137.342 ms 141.130 ms
3 192.168.200.30 (192.168.200.30) 136.752 ms 133.869 ms 135.960 ms
We can see the traffic is going through the 10.0.0.2 interface.
We also can check the routing table on the VPN gateway on network A :
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.200.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
0.0.0.0 212.x.x.x 0.0.0.0 UG 0 0 0 eth1
We see any traffic directed to 192.168.200.0/255.255.255.0 must go through interface 10.0.0.2 on device tun0.
Making sure the VPN connection is established at boot (Debian way) :
Edit /etc/defaults/openvpn and specify which VPN network must be started.
Make OpenVPN starts at boot with this command :
update-rc.d openvpn defaults
OpenVPN will start any VPN configuration named *.conf found in /etc/openvpn/
So don’t store copies of config like test.conf test-backup.conf as OpenVPN will try to start them at boot.
January 5, 2008 -
Today, I had to recover some data from a (badly) failed drive.
The drive was coming from a laptop. I first tried to recover stuff using the Ubuntu Live CD on the laptop, but it didn’t work. Whenever I was trying to install the necessary tools in the Live CD environment, the system was hanging and throwing IO errors from the failed drive.
I attached the drive (using a 2″1/2 to 3″1/2 adapter) to my desktop machine and booted under Ubuntu.
It was impossible to mount the drive directly (returning IO errors immediately).
dd was not able to copy the content of the drive, because of the bad sectors.
The tool dd_rescue (from the package ddrescue) came to help.. It found errors at around 2.8 GB and 13 GB but kept going. I’m now in possession of a file that can be mounted and I can recover the precious files.
Usage : dd_rescue -l errors.log /dev/sdc1 /path/to/destination/diskdump
Here’s the description of ddrescue : copies data from one file or block device to another
dd_rescue is a tool to help you to save data from crashed partition.
It tries to read and if it fails, it will go on with the next sectors
where tools like dd will fail. If the copying process is interrupted
by the user it is possible to continue at any position later.
It can copy backwards.
gddrescue, dcfldd and rdd are apparently similar tools. I haven’t tested them.
Searching for the word “forensic” in Synaptic returned some interesting tools.
foremost : Forensics application to recover data
This is a console program to recover files based on their headers and
footers for forensics purposes.
Foremost can work on disk image files, such as those generated by dd,
Safeback, Encase, etc, or directly on a drive. The headers and footers
are specified by a configuration file, so you can pick and choose which
headers you want to look for.
Usage : foremost -t jpg -i diskdump
This would recover jpg files from diskdump and copy the recovered files in the current directory
vinetto : A forensics tool to examine Thumbs.db files
A tool intended for forensics examinations. It is a console program to extract
thumbnail images and their metadata from those thumbs.db files generated under
Windows. Used in forensic environments.
Usage : vinetto Thumbs.db -o /tmp/dir
This would recover the cached preview images from Thumbs.db into /tmp/dir
sleuthkit : Tools for forensics analysis
The Sleuth Kit (previously known as TASK) is a collection of UNIX-based
command line file system and media management forensic analysis tools.
The file system tools allow you to examine file systems of a suspect
computer in a non-intrusive fashion. Because the tools do not rely on
the operating system to process the file systems, deleted and hidden
content is shown.
You can use “autopsy” as front-end to sleuthkit.
gdmap : Tool to visualize diskspace
GdMap is a tool which allows to visualize disk space. Ever wondered why your
hard disk is full or what directory and files take up most of the space? With
GdMap these questions can be answered quickly. To display directory
structures cushion treemaps are used which visualize a complete folder or even
the whole hard drive with one picture.
The purpose here was to recover files from a failed drive.. not doing forensics, so only dd_rescue was really needed today.
I’ll try to keep a list of useful recovery/forensics tools in this post.
If you have suggestions about tools, technique, etc. drop me a line.
December 30, 2007 -
Based on http://e18.physik.tu-muenchen.de/~tnagel/ipt_recent/
The following example is much simpler, it blocks hosts trying to connect more than 3 times to the SSH server within 60 seconds. If you need something more complex, check out the howto mentionned above.
This is my /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:LIMIT_SSH - [0:0]
# accept localhost and related/established traffic
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
# transfer connections made to tcp/22 to the LIMIT_SSH chain
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j LIMIT_SSH
# block anything else in the INPUT chain
-A INPUT -j DROP
# if host has made more than 3 attempts in 60 seconds, drop it
-A LIMIT_SSH -m recent --set --name SSH
-A LIMIT_SSH -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
-A LIMIT_SSH -j ACCEPT
COMMIT
Recent module homepage : http://www.snowman.net/projects/ipt_recent/
December 29, 2007 -
On the log server :
Edit /etc/sysconfig/syslog and change SYSLOGD_OPTIONS to match the following :
SYSLOGD_OPTIONS="-m 0 -r -s example.com"
-r : listen over the network, only necessary for log servers
-s : strip that value out of the logs (client.example.com would become client in the logs)
Restart the service :
# service syslog restart
The server will start listening on UDP/514
Make sure you allow that port in the firewall configuration on the log server
On the “client” (machine sending the logs) :
Edit /etc/syslog.conf and add the following line :
*.* @loghost.example.com
By adding that line and keeping the default config, the logs will be stored on the client machine and sent to the log server as well.
Restart the service :
# service syslog restart
Restart a service (like ntpd.. whatever) and check the log messages appearing on the log server.
Obviously, this post is just a reminder.
Please remember syslog uses UDP, which is an unreliable transport.
During an attack, packets could be dropped and log messages along.
Also there’s no authentication, an attacker could send fake log messages to the log server.
Logs are sent in clear text as well.
Syslog-ng addresses all these issues :
http://www.balabit.com/network-security/syslog-ng/
October 5, 2007 -
I’ll explain the few commands used to enable DHCP snooping on our Catalyst switch at work.
The users aren’t really tech savvy or anything, but it is painless to configure so it is worth having it enabled.
switch1>enable
First, we need to know which VLAN the DHCP server belongs to, “show arp” has that info :
switch1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.3 1 0004.75XXXXXX ARPA Vlan1
Then we enable configuration mode :
switch1#conf term
Enabling DHCP snooping on VLAN 1 :
switch1(config)#ip dhcp snooping
switch1(config)#ip dhcp snooping vlan 1
switch1(config)#ip dhcp snooping information option
The DHCP server is connected to the second port, we will add that interface to the trusted list :
switch1(config)#interface fastEthernet 0/2
switch1(config-if)#ip dhcp snooping trust
Let’s review the config :
switch1#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
———————— ——- —————-
FastEthernet0/2 yes unlimited
DHCP snooping is enabled on VLAN 1 for interface 2 !
Saving the config :
switch1#copy running-config startup-config
August 11, 2007 -
My friend Jonathan just told me about a nice command to debug SSL SMTP :
$ openssl s_client -connect mail.server.be:465
Example :
$ openssl s_client -connect smtp.gmail.com:465
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDYzCCAsygAwIBAgIQYZrZzKZNh1fKVFuUlZ6rKzANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA3MDczMDE2NTgwN1oXDTA4MDcyOTE2NTgwN1ow
aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1v
dW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnNtdHAu
Z21haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQF2mUMNM+qw/i
wMVSP2D0pgKb0M3RyWHBTQkno3W4y5TeH8LALnqv9/+Th4wZ5PrZ7YPQjmCxdtz6
Lm5Yx19nDXNw97or6SXvAoZSF+bwh76UFqxpImAGJzvj8Ro7rNkMidJa+KgGaIng
sIcWuqsj0rrK1AXoUHKmO4N5t0c6XwIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRo
YXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAyBggrBgEFBQcBAQQm
MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wDAYDVR0TAQH/
BAIwADANBgkqhkiG9w0BAQUFAAOBgQCUoTmFzdJX+2Pz9FhI+H88lFIeBcFnxpPO
CHO7zs/J3ZI6ZmkuQm4az89tRqvKvRFrQm2CRlzntqWjSdcsIYlKKGZ32iclpNKw
1aW/Q3IIyyZTTUo9DJezyCrFBV7JxFXOQgYd45+YxPVUNnkw1lTd4RqweuB5p7r4
nObS2EE7cA==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
No client certificate CA names sent
---
SSL handshake has read 1025 bytes and written 308 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DES-CBC3-SHA
Session-ID: CC361F3727F3119BA597CDACDBA425B4E4BF91C788AA3F3812BD853E3D06B1BF
Session-ID-ctx:
Master-Key: D99E897D9B128AFC1525E18BF0E2B55DA60D5357D3E8BEC497AC81561DF22A3C7F8B6EB58E01D7F9F5676BAB1B10FC0D
Key-Arg : None
Start Time: 1186787801
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
220 mx.google.com ESMTP h7sm7864128nfh
This will work with anything-SSL (pop3s, imaps, https, etc.)
Thanks Jonathan ! 
July 26, 2007 -
Install needed packages :
# apt-get install cryptsetup
Load modules (if needed) :
# modprobe aes
# modprobe dm_mod
# modprobe dm_crypt
LUKS on a free partition :
# cryptsetup luksFormat -c aes -h sha256 /dev/hda6
This would erase any data on the partition !
THE PARTITION SHOULD NOT BE MOUNTED, if so “umount /dev/hda6″
Formating the newly created partition :
# cryptsetup luksOpen /dev/hda6 secure
# mkfs.ext3 /dev/mapper/secure
where “secure” is the name given to the encrypted partition.. it would result in a device name like /dev/mapper/secure
Mount manually into the /secure directory :
mount -t ext3 /dev/mapper/secure /secure
Unmount :
# umount /secure
# cryptsetup luksClose secure
Automatically mounting at boot :
Edit /etc/crypttab like this :
secure /dev/hda6 none luks
Edit /etc/fstab like this :
/dev/mapper/secure /secure ext3 defaults 0 1
You would be prompted for the LUKS password at each boot.
Using a LUKS partition may slow down your system. I haven’t tested the impact of LUKS yet. You can always “renice” the daemon responsible for the encryption :
$ sudo renice 10 `pgrep kcryptd`
Links :
http://doc.ubuntu-fr.org/cryptsetup
https://help.ubuntu.com/community/EncryptedFilesystemHowto
Next Page »
