While upgrading my MIPv6 Mobile Node (my main laptop) to latest kernel (2.6.34), I noticed a regression which breaks MIPv6 supports. The regression was introduced by commit f4f914b5 (net: ipv6 bind to device issue) after 2.6.34-rc5.
Once reported on netdev, a fix was proposed by Brian Haley, and then applied by David Miller to his net-2.6 tree. It is now sitting in Linus tree (commit 6057fd78: IPv6: fix Mobile IPv6 regression).
The fix has also been pushed to the stable team. It did not make it for 2.6.34.1 (i.e. that version has the regression) but will be in 2.6.34.2. If you need the patch for your 2.6.34 or 2.6.34.1, the commit in Linus tree (6057fd78) will apply fine and fix the regression.
MIPv6 signaling traffic uses Home Address Option (carried in a Destination Option Header) and Type 2 Routing Header. Those elements found in BU and BA packets carry the HoA of the MN in an explicit fashion. But they are in fact useless and can be removed (at least when IPsec is used).
If you are interested by the details, I have just dedicated a page to the topic here.
My solution to SSTIC 2010 Challenge (in french) is available on the challenge's page. I encourage the interested reader to take a look at the other documents published on the site. Among others:
Mathieu also posted an interesting solution here.
I started looking at what is needed to get current linux-omap kernel running on Nokia N900. This is a work in progress; do not expect much yet but do not hesitate to tell if you can help!
I added an entry on the N900 custom kernel page describing how to build and install a 2.6.28.10-omap1-grsec kernel on your N900:
oslo:~# uname -a Linux oslo 2.6.28.10-omap1-grsec #1 PREEMPT Sun Mar 7 01:20:47 CET 2010 armv7l
Nothing complicated, but at least it is kind of documented now.
The N900 custom kernel page now contains an entry describing how to build and install 2.6.28.10-omap1 kernel on your N900.
I have set up a N900 repository. It is currently populated with emacs 23.1.93, umip and racoon-umip. If you want to give it a try, you can either use this link or add the repository manually (Application manager > Application catalogs > New) using following parameters:
If you want to pass it to apt-key, the repository key is here with its signature:
n900# wget -q http://natisbad.org/debian-n900/n900-debian-repo.key n900# wget -q http://natisbad.org/debian-n900/n900-debian-repo.key.sig n900# gpg --verify n900-debian-repo.key.sig gpg: Signature made Wed 03 Mar 2010 10:57:03 AM CET using RSA key ID A7AE341B gpg: Good signature from "Arnaud Ebalard <arno@natisbad.org>" n900# apt-key add n900-debian-repo.key OK
I finally found some time to spend on building and packaging the latest version of Emacs (23.1.93) for the N900.
I had previously written about doing things properly for Emacs 22.2 (here) but had some qemu issues while doing the same for Emacs 23.1.
I gave Emacs 23.1.93 a try and things worked flawlessly. More details are available here.
A few weeks ago, I received an email from Debian Bug Tracking System indicating that Bug#485963 had been fixed in apt 0.7.25.1:
This is an automatic notification regarding your Bug report which was filed against the apt package: #485963: APT https method has no option for checking CRL It has been closed by Michael Vogt <mvo@debian.org>.
If you are running an up-to-date Debian unstable and use apt-transport-https (additional modules for apt which provides the ability to connect to https mirrors) you might be interested by the following.
In June 2009, I submitted patches for APT https method improvements
Client Authentication patch has been merged upstream shortly after submission.
The CRL and Issuer check patch was made possible by patches developed by Axel and I for libcurl (see this post) and merged upstream by curl maintainers. But that updated version was not available in Debian packages at the time of APT patches submission. Some time spent and Debian libcurl package now has our patches. APT has been updated as expected. No need to repeat here what is now available on your system:
arno@small$ zless /usr/share/doc/apt/examples/apt-https-method-example.conf.gz ...
My old 1024-bit DSA-based GPG key (0x47A5026) was about to expire. So I decided to go for a fresh stronger one (4096-bit RSA). Here is its fp: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B
Below are few lines of C similar to some code I recently encountered while debugging an application:
$ cat test.c
#include <unistd.h>
int main(int argc, char *argv[]) {
ssize_t len;
char buf[4];
len = read(0, buf, sizeof(buf));
if (len < sizeof(buf))
return 1;
return 0;
}
Once compiled and run, it reads data from standard input:
$ gcc -Wall -pedantic test.c $ echo -n "aaaa" | ./a.out ; echo $? 0 $ echo -n "aaa" | ./a.out ; echo $? 1
A description for the program could be: It returns 0 if there was at least 4 bytes received. It returns 1 if there was less than 4 bytes received or upon read() error.
But the program is in fact buggy and for that reason, its behaviour does not match previous description. Can you see why?
Here is an excerpt of read() man page, in case you wonder if you have missed something about read() behavior.
READ(2) Linux Programmer's Manual READ(2)
NAME
read - read from a file descriptor
SYNOPSIS
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
DESCRIPTION
read() attempts to read up to count bytes from file descriptor
fd into the buffer starting at buf.
If count is zero, read() returns zero and has no other
results. If count is greater than SSIZE_MAX, the result is
unspecified.
RETURN VALUE
On success, the number of bytes read is returned (zero
indicates end of file) [...]. On error, -1 is returned, , and
errno is set appropriately.
...
ERRORS
...
EBADF fd is not a valid file descriptor or is not open for
reading.
Still no clue? Here is a hint: check more carefully what happens if read() fails for some reason. In fact, let's make it fail for real:
$ sh -c "./a.out 0<&-" ; echo $? 0
As you can see, the return value of our test program is 0 when 1 was expected. In previous command, <&- is used to tell the shell to close standard output. The result is that read() fails with a return value of -1. strace can be used to verify that.
$ strace -f sh -c "./a.out 0<&-"
...
[pid 26641] mprotect(0xb7735000, 8192, PROT_READ) = 0
[pid 26641] mprotect(0xb777b000, 4096, PROT_READ) = 0
[pid 26641] munmap(0xb773b000, 133666) = 0
[pid 26641] read(0, 0xbfadb67b, 1) = -1 EBADF (Bad file descriptor)
[pid 26641] exit_group(0) = ?
Process 26640 resumed
Process 26641 detached
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 26641
--- SIGCHLD (Child exited) @ 0 (0) ---
dup2(10, 0) = 0
close(10) = 0
exit_group(0) = ?
The problem is that read() returns a ssize_t (i.e. a signed int), in order to support positive values when something was indeed read and negative values upon error. Of course, you already know that because you read the man page.
But the comparison which follows read() call is between a size_t (the return value of sizeof() call, i.e. an unsigned int) and a ssize_t (signed one). You have now guessed what has happened: automatic type conversion has resulted in the conversion by gcc of our signed int (-1) into an unsigned int (4294967295 on my 32-bit little-endian system).
Section 2.7 (Types Conversions) of K&R2 (worth reading) has the following about such lossy conversions: Expressions that might lose information, like assigning a longer integer type to a shorter, or a floating-point type to an integer, may draw a warning, but they are not illegal. Sounds like fun. Additionally,
I guess some readers may have scrolled up in order to verify compilation flags (-Wall -pedantic were used) and are now wondering why gcc did not issue a warning during compilation. Well, warning for comparisons between signed and unsigned expressions that may lead to incorrect results due to conversion are issued when -Wsign-compare is used:
$ gcc -Wall -pedantic -Wsign-compare test.c test.c: In function 'main': test.c:8: warning: comparison between signed and unsigned integer expressions
To be clear, -Wsign-compare is not enabled by -Wall. It is enabled by -Wextra with additional options you might be interested in taking a look at. Below is an excerpt of gcc man page:
$ man gcc
...
-Wsign-compare
Warn when a comparison between signed and unsigned values could
produce an incorrect result when the signed value is converted
to unsigned. This warning is also enabled by -Wextra; to get
the other warnings of -Wextra without this warning, use -Wextra
-Wno-sign-compare.
...
-Wall
This enables all the warnings about constructions that some
users consider questionable, and that are easy to avoid (or
modify to prevent the warning), even in conjunction with
macros. This also enables some language-specific warnings
described in C++ Dialect Options and Objective-C and
Objective-C++ Dialect Options.
Note that some warning flags are not implied by -Wall.
Some of them warn about constructions that users generally
do not consider questionable, but which occasionally you
might wish to check for; others warn about constructions
that are necessary or hard to avoid in some cases, and
there is no simple way to modify the code to suppress the
warning. Some of them are enabled by -Wextra but many of
them must be enabled individually.
...
-Wextra
This enables some extra warning flags that are not enabled by
-Wall. (This option used to be called -W. The older name is
still supported, but the newer name is more descriptive.)
-Wclobbered -Wempty-body -Wignored-qualifiers
-Wmissing-field-initializers -Wmissing-parameter-type (C only)
-Wold-style-declaration (C only) -Woverride-init -Wsign-compare
-Wtype-limits -Wuninitialized (only with -O1 and above)
-Wunused-parameter (only with -Wunused or -Wall)
The option -Wextra also prints warning messages for the following cases:
- A pointer is compared against integer zero with <, <=, >, or >=.
...
...
If you are interested by further reading on such issues, I would suggest taking a look at Chapter 6 (C language issues) of "The Art of Software Security Assessment" (great book).
Thanks to Nico and Sarah for the interesting discussions and pointers on the topic.
I have written a page discussing Scapy extensions I have developed and their status. At the moment, it provides information on:
I will try and add soon some additional entries there about the following:
I have added some new entries on my N900 page discussing:
After having spent some time on the N770, worked on installing a full debian and a recent kernel on my N810, I have just bought last week the recently released Nokia N900 to work on IPv6 mobility aspects for the device.
As this involves playing with the kernel, the distribution and the hardware available on the device, I have started putting some notes and links on a dedicated page.
At the moment, it provides information on how the kernel can be updated to support additional options (in my case, MIPv6 and IPsec/IKE-related options).
Going from Paris to Amsterdam is only 4 hours using Thalys train. And if you happen to travel in Comfort 1 (it is sometimes cheaper than Comfort 2) you also get:
The Internet access is IPv4 only but Teredo traffic is not filtered, which allows you to get IPv6 connectivity and that way use MIPv6.
Nonetheless, if you happen to do that, even if your private IPv4 address remains stable during the journey, you should be aware that your NAT gateway will change at some points. For that reason, you may have to restart your Teredo service when you lose connectivity, in order for the Teredo qualification procedure (which results in the detection of the NAT GW IP address and in the creation of your IPv6 address, among other things) to be redone.
That been said, the network works perfectly fine.
If you have a Dell E4300 (or any other Dell laptop with a Broadcom USH) running Linux, I updated my page dedicated to the E4300 with some additional information. This includes patches and firmware upgrades notes to get the SmartCard reader to work with a Cryptoflex E-Gate 32K.
I hope that helps.
If you are interested by installing a Debian and a recent linux kernel (2.6.30-rc8-omap1) on your N810 as a replacement for Maemo and its 2.6.21 kernel, I have gathered some notes on the topic.
This is a work in progress, so be gentle!
For those among you who use FreeRADIUS for AAA service in a 802.1X setup (wired, WPA/WPA2), you should be aware that EAP-TLS support is broken since 2.1.0, i.e. September 4 2008. This means 2.1.0, 2.1.1, 2.1.2 and 2.1.3 are broken.
Simply put, a removed test in the code in those versions prevents FreeRADIUS to send last messages of the TLS exchange to the client (TLS Change Cipher Spec and TLS Finished). Even though, the server still sends the final RADIUS Access Accept message to the NAS (including the EAP Success message for the peer). The TLS exchange being incomplete from the client standpoint, it simply fails.
I first reported the issue on the list and ended up git-bisecting it. This led me to commit b51a3a82edb797f5d0a2758bd1a38359d6f66803, which was only expected to "Clean up debug && log messages".
I posted the patch below which fixes the issue. It should apply cleanly if you need to patch one of the broken versions. It has been merged upstream and 2.1.4 should be ok.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Axel Tillequin <axel.tillequin@gmail.com>
---
src/modules/rlm_eap/libeap/eap_tls.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/modules/rlm_eap/libeap/eap_tls.c b/src/modules/rlm_eap/libeap/eap_tls.c
index cd95bec..42edbed 100644
--- a/src/modules/rlm_eap/libeap/eap_tls.c
+++ b/src/modules/rlm_eap/libeap/eap_tls.c
@@ -330,7 +330,8 @@ static eaptls_status_t eaptls_ack_handler(EAP_HANDLER *handler)
return EAPTLS_FAIL;
case handshake:
- if (tls_session->info.handshake_type == finished) {
+ if ((tls_session->info.handshake_type == finished) &&
+ (tls_session->dirty_out.used == 0)) {
RDEBUG2("ACK handshake is finished");
/*
--
1.5.6.5
If you are interested, the whole thread on freeradius-devel mailing list is available here.
Linux 2.6.27.13 kernel has been released by the -stable team. The associated enhanced MIGRATE patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Note that those patched 2.6.27.13 tarballs are intended for those who cannot switch to 2.6.28 series (MIGRATE patches have been merged upstream).
I have just uploaded new versions of ipsec-tools-umip (0.7-12), racoon-umip (0.7-12) and umip (0.4-11) packages.
Those include fixes, enhancements and new features: they result from time spent testing the code on a large testbed. Some experiments involved more than 100 Mobile Nodes handled by a single Home Agent.
The instruction to set things up are still available here.
Also note that I have updated the mercurial versioned quilt set available here for 2.6.28: at the moment, it mainly contains a simple fix to deal with the fact that internal kernel code does not currently like when a MIGRATE message is received for a larval SA. I will push the fix on netdev as soon I am sure not migrating larval SA is the path to follow.
Linux 2.6.27.10 kernel has been released by the -stable team. Among the fixes, there is an IPsec-related fix:
commit 123cd635a810bea55c41f09c09e4d6dc1f493876
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri Oct 31 16:41:26 2008 -0700
key: fix setkey(8) policy set breakage
commit 920da6923cf03c8a78fbaffa408f8ab37f6abfc1 upstream.
The associated enhanced MIGRATE patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.27.9 kernel has been released by the -stable team. The associated enhanced MIGRATE patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Like for previous stable release, there are a huge number of fixes in that release (more than 80). You are strongly encouraged to upgrade!
Thanks to San Francisco's Apple Store for the connectivity used to upload those tarballs.
Linux 2.6.27.8 kernel has been released by the -stable team. The associated enhanced MIGRATE patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Considering the number of fixes (103 commits in the Changelog !!!), you are strongly encouraged to upgrade.
I am pleased to announce that Timo Teräs has just commited upstream the MIGRATE/KMADDRESS support I have developped for racoon:
$ cat Changelog
2008-12-05 Timo Teras <timo.teras@iki.fi>
From Arnaud Ebalard <arno@natisbad.org>:
* src/libipsec/{key_debug.c|libpfkey.h|pfkey.c}: library functions
for SADB_X_EXT_KMADDRESS and updated SADB_X_MIGRATE support
* src/racoon/{handler.c|handler.h|ipsec_doi.c|isakmp.c|
isakmp_quick.c|pfkey.c|policy.c|policy.h}: support Mobile IPv6
per draft-ebalard-mext-pfkey-enhanced-migrate (minor fixes to
the patch by me)
...
The size of the patch (> 2000 lines) explains the time its integration has taken. I will soon update the howto to reflect the upstream merge.
Timo, thanks again for your work.
Andreas Steffen has developed MIGRATE/KMADDRESS support for Charon, the IKEv2 daemon of strongSwan. No backport is expected for Pluto, the IKEv1 daemon.
It is available in the recently released 4.2.9 version. Below is an excerpt of the changelog:
Mobile IPv6 support ------------------- Basic Mobile IPv6 support has been introduced, securing Binding Update messages as well as tunneled traffic between Mobile Node and Home Agent. The installpolicy=no option allows peaceful cooperation with a dominant mip6d daemon and the new type=transport_proxy implements the special MIPv6 IPsec transport proxy mode where the IKEv2 daemon uses the Care-of-Address but the IPsec SA is set up for the Home Address. http://wiki.strongswan.org/wiki/MobileIPv6 Fully supports migration of Mobile IPv6 connections making use of the KMADDRESS field contained in XFRM_MSG_MIGRATE messages sent by the mip6d daemon via the Linux 2.6.28 (or appropriately patched) kernel.
I will try and find some time to give it a try and add some configuration information in the howto.
(For a while now) MIGRATEv2-patched Linux 2.6.27.7 kernel tarball is available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
I have just uploaded a new release of UMIP (0.4-10) Debian packages (i386 and ppc) including an updated NEPL patch and a fix for memory corruption on HA.
I have just uploaded a new release of UMIP (0.4-9) Debian packages (i386 and ppc) including additional patches. Those patches are still available as a quilt set versioned via mercurial.
Among the recent changes I have included a patch that fix a compilation issue with 2.6.28 kernel series. Another patch fixes a bug that occurs on HA when providing multiple times the same interface (which is likely to happen when you deal with many MNs and split configuration for those MN between multiple files).
I have also released new versions of ipsec-tools-umip and racoon-umip (0.7-9) Debian packages (i386 and ppc), based on latest CVS release (2008-11-27). The patches are available here
The instructions for setting things up (kernel, umip, racoon) can still be found here.
A few hours ago, I have submitted my IETF draft on MIPv6 IPsec Route Optimization mechanism (IRO). It is now available from IETF servers.
I also (cross)posted about the submission on mext, ipsecme and mobopts mailing lists in order to get some feedback.
I have just uploaded a new release of UMIP (0.4-8) Debian packages (i386 and ppc) including additional patches. Those patches are still available as a quilt set versioned via mercurial. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Among the recent changes I have included a patch that removes the need for the administrator of the HA to manually set /proc/sys/net/ipv6/conf/XXX/proxy_ndp (with XXX the interfaces referenced in the configuration file). This was not documented in the howto and should be done by UMIP anyway.
Linux 2.6.27.6 kernel has been released by the -stable team. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.27.5 kernel has been released by the -stable team. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
MIPv6 provides a Route Optimization procedure which allows direct communications (not routed via the HA, i.e. following natural routing path) to happen between a MN and a CN (or two MN).
This procedure is complicated, does not provide protection of data traffic and is based on low hypothesis with respect to the credentials shared by the two entities.
Considering different hypothesis, more in sync with IPsec environments (availability of PKI and ability to establish IKE negotiations between peers), I have written an IETF draft which I intend to post (and implement) at some point.
In IPsec environments (protection of signaling and data traffic using IPsec/IKE), proposed solution is expected to offer the following advantages:
Anyway, it is available here. You can clone the mercurial repository using the following command:
$ hg clone http://hg.natisbad.org/iro-draft
Comments are welcome but keep in mind it is still a work in progress and has currently a fairly raw shape, so please be gentle.
Some time ago, I posted patches on netdev providing KMADDRESS support for Linux kernel. This was accepted and will be in 2.6.28. But ...
While adding support for MIGRATE/KMADDRESS in strongSwan, Andreas Steffen noticed that XFRMA_KMADDRESS attribute passed to userland contains the local address twice (remote provides local address instead of remote one).
This is a bug in copy_to_user_kmaddress() which affects only key managers that use native XFRM interface. Key managers that use PF_KEY (like racoon) are not affected, which is probably the reason I never noticed the bug. For the record, the bug was in the initial changeset I posted which added support for KMADDRESS (commit 13c1d18931ebb5cf407cb348ef2cd6284d68902d).
This morning, I posted a one line patch on netdev, which David Miller applied 3 minutes later. I like that kind of timing ;-)
Note that I have also updated 2.6.27.4 tarballs (-02). Those are available at the usual location.
Linux 2.6.27.4 kernel has been released by the -stable team. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.26.7 and 2.6.27.3 kernels have been released by the -stable team. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
I posted on ipsec-tools-devel the whole set of patches I have written to add support for enhanced MIGRATE (i.e. SADB_X_MIGRATE and SADB_X_EXT_KMADDRESS) in racoon, as specified in draft-ebalard-mext-pfkey-enhanced-migrate-00.
Considering the amount of code, I expect the inclusion to take quite some time. I will post here when it is completed.
Linux 2.6.27 kernel has been released by Linus. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.26.6 kernel has been released by the -stable team. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.27-rc9 kernel has been released by Linus. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
I posted some monthes ago (in June) about patches I wrote (w/ Axel) for APT https method providing:
Just released apt-transport-https (0.7.15+b1) includes the patches for the first 3 previous items:
$ zless /usr/share/doc/apt-transport-https/changelog.gz
...
* merge patch that enforces stricter https server certificate
checking (thanks to Arnaud Ebalard, closes: #485960)
* allow per-mirror specific https settings
(thanks to Arnaud Ebalard, closes: #485965)
* add doc/examples/apt-https-method-example.cof
(thanks to Arnaud Ebalard, closes: #485964)
...
The remaining patches for CRL support and issuer checks require the most recent version of libcurl (7.19.0), not available yet in Debian. I will post here when apt is updated to support those features.
The MIGRATE enhancement patch I posted on netdev has just being applied to net-next-2.6 by David Miller. This will make 2.6.28 kernel fully compliant with what is in enhanced MIGRATE draft.
Patched tarballs for 2.6.27-rc* series and 2.6.27 will still be available at the usual location.
Now that the draft is available and the associated kernel part of the work has been completed, integration of the userland patches (ipsec-tools and UMIP) is the only remaining part and the next item on my todo list.
Unrelated (or not): Nokia people (maemo developers) are currently pushing an impressive number of patches for inclusion in 2.6.28 (phonet stack, SSI, omap3 code, ...). It looks like the future big brother of the N810 will have a more open source support and will possibly run a more recent kernel (2.6.28 omap ?). My guess is that having MIPv6/IPsec/IKE on it will possibly be just trivial in that case.
My (one line) patch correcting a bug in ip6_dst_blackhole_ops.kmem_cachep init has been applied to net-2.6, pushed back to linus-tree (i.e. will be in 2.6.27-rc9) and queued for inclusion in -stable (2.6.26.6 hopefully).
I posted a bug report against Debian starttls package. I flagged it as critical and still think it deserves that severity level. The maintainer provided some lame comments and changed the security level to wishlist. I am puzzled, to say the least.
Linux 2.6.27-rc7 kernel has been released by Linus. The associated MIGRATEv2-patched tarball is available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.26.5 kernel has been released by the -stable team. 2.6.27-rc6 has also been published by Linus. The associated MIGRATEv2-patched tarballs are available here.
I have also updated MIGRATEv2 patches for latest CVS version of racoon. Updated Debian packages of ipsec-tools-umip and racoon-umip for i386 and ppc are available from the mirror.
The instructions for setting things up (kernel, umip, racoon) can still be found here.
I have just submitted an individual IETF Internet Draft (co-authored with Sebastien Decugis) describing the enhancements to MIGRATE design associated with the set of patches I maintain here for Linux Kernel, UMIP and racoon.
The document (including HTML/TXT versions) is available here.
I have added some notes at the end of MR-related part on MIPv6 page dedicated to the routing configuration on the MR.
Linux 2.6.26.2 kernel has been released by the -stable team. 2.6.27-rc2 has also been published by Linus. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
Linux 2.6.26.1 kernel has been released by the -stable team. The associated MIGRATEv2-patched tarballs are available here. The instructions for setting things up (kernel, umip, racoon) can still be found here.
The patch I submitted to OpenSC developers providing an implementation for PKCS11_private_encrypt() (required to be able to use OpenSSL RSA_private_encrypt() w/ tokens) has been applied to libp11 trunk.
One concern was that there has been no new stable release of libp11 for a while (0.2.3 was one year old, in fact) and developers did not expect one in a near future but ... a Security vulnerability against OpenSC the day after resulted in new stable releases for all parts of the project (OpenCT, OpenSC, Libp11, Pam_P11, Engine_PKCS11) cleared that concern: libp11 0.2.4 has the feature.
I then filled a bug report (wishlist severity) to have the Debian package updated to the new version.
Two weeks ago, I wrote about the inability to use OpenSSL RSA_sign() in IKE context because:
As suggested by Stephen Henson on openssl-dev ML, the solution is to use RSA_private_encrypt() low-level signature function. As a side note, this is in fact what RSA_sign() does internally: after having added the digest information before the hash value, it simply make a call to RSA_private_encrypt() to have the padding and RSA private key encryption done.
When using a RSA key from a file (PEM/DER), this works just fine.
Now, when using OpenSC PKCS#11 module via OpenSSL dynamic engine interface, this cannot work (yet). The reason is that current implementation of PKCS11_private_encrypt() found in libp11 (p11_ops.c file) is an empty shell:
int
PKCS11_private_encrypt(int flen, const unsigned char *from, unsigned char *to,
const PKCS11_KEY * rsa, int padding)
{
/* PKCS11 calls go here */
PKCS11err(PKCS11_F_PKCS11_RSA_ENCRYPT, PKCS11_NOT_SUPPORTED);
return -1;
}
To solve the issue, I have submitted a patch that provides an implementation for PKCS11_private_encrypt() (so that OpenSSL's RSA_private_encrypt() also works with dynamic engines based on OpenSC PKCS#11 module). The patch also avoid code duplication by having PKCS11_sign() use PKCS11_private_encrypt().
The post (including the patch) on opensc-devel ML is here.
I have written a detailed howto that describes the deployment of IPsec/IKE-protected MIPv6 under Linux. This covers both the theoretical (design, associated reference documents and their status) and practical aspects (patches, build, configuration, packages) of the topic. The setup is based on racoon and umip.
Everything is here.
I made some announcements on various mailing lists:
If you have questions, bug reports or ideas, do not hesitate to drop me a mail.
While playing with OpenSSL engine code to add smartcard support to racoon, I discovered the following issue that currently prevents RSA_sign() to be used in IKE context.
RSA_sign() provides PKCS#1 signature: to sum up the step of events, it takes a buffer and its length (holding the digest of a message), adds an OID providing digest information before the hash (based on the type of hash used, the first parameter of the function), pads the result to RSA modulus length and then private encrypts the result. Function prototype is the following:
#include <openssl/rsa.h>
int RSA_sign(int type, const unsigned char *m, unsigned int m_len,
unsigned char *sigret, unsigned int *siglen, RSA *rsa);
The 'type' argument is of particular interest in the rest of the discussion. The man page describes it that way:
type denotes the message digest algorithm that was used to generate m. It usually is one of NID_sha1, NID_ripemd160 and NID_md5 [...] If type is NID_md5_sha1, an SSL signature (MD5 and SHA1 message digests with PKCS #1 padding and no algorithm identifier) is created.
Now, below is an excerpt of Section 5.1 of RFC 2409, which describes how RSA signature should be performed:
Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format and not as a signature in PKCS #1 format (which includes the OID of the hash algorithm).
Basically, this is the same needs as for SSL/TLS (NID_md5_sha1 for type argument), where no OID is added before the 36 byte concatenation of MD5 and SHA1 hashes: the hashes are simply padded and private key encrypted.
OpenSSL code (and also libp11 OpenSSL abstraction layer for RSA_sign() if you use tokens) has specific a length check (36 bytes) of provided hash if you use NID_md5_sha1.
Hence the post on openssl-dev.
n.b.: and no, using RSA_private_encrypt() is not a solution because this would require to flag associated keys on token as encryption capable.
While playing with OpenLDAP and setting up TLS authentication via SASL EXTERNAL mechanism, I found a bug in libldap CRL support (GnuTLS backend only) that prevented the daemon to start. Clients with CRL support activated are also impacted.
The bug was in libldap code, more specifically in GnuTLS-specific part of the code (in ldap_int_tls_init_ctx() in librairies/libldap/tls.c) : gnutls_certificate_set_x509_crl_file() was expected to return 0 when everything went fine, where it in fact returns the number of CRL found in the given file. Caller did not like that non null value, resulting in failure.
You can find more details in the bug report I posted. This was quickly (OpenLDAP developers are very reactive) commited to HEAD
While pushing the bug report, I was wondering how it was possible that this bug was still sitting there: it should have been discovered a long time ago. The answer to this question is certainly that real deployments of OpenLDAP that make use of TLS use OpenSSL backend, and not GnuTLS. For non-technical reasons, Debian links libldap against GnuTLS library.
BTW, there is an interesting thread on the topic here, which may lead you to maintain your own version of libldap package, linked against libssl...
APT is the debian package management utility. It nativaley supports different methods to access Debian repositories: ftp, http, file, cdrom, ...
An additional package - namely apt-transport-https - adds support for another method: https. Because the content of mirrors can/should be protected by apt-secure (GPG signature of lists of packages hashes) even for custom non-official repositories, the interest of https might not be obvious. Nonetheless, if you need to
then, https is a simple and efficient solution.
I will not cover the Apache part of the setup here but if you are interested, drop me a mail. After this introduction, let's go directly to the point: Debian APT https method.
Some facts on apt-transport-https package:
Hummm, it does not look good. Well, Axel and I spent some time to improve the picture. We wrote two sets of patches:
At the time of writing, cURL patches are in project's CVS and will be in 7.19.0 which should be released in August. It will then quickly be available under Debian unstable which will allow me (after some tests) to bug again APT maintainers for inclusion of the patches. I'll made a post on this page as soon as there is some progress (probably at the beginning of September).
While playing with a nfnetlink_queue updated version of NTT Docomo SEND daemon (vanilla version is based on ipqueue), I discovered a bug introduced in 2.6.24.4 (yes, by a -stable set of patches) that prevents enlarged reinjected packets to be sent. I posted a patch on netdev that made its way to Linus tree (2.6.26-rc1 and later are ok) and was pushed by -stable team in 2.6.25.4.
Here is the resend on netdev (first post slipped through), with the explanations and the patch (should apply w/o problem on all kernels that have the bug). Then, the patch was pushed to Linus tree, here. It was then released by the -stable team as part of the set of patches for 2.6.25.4