New extension: CRYPT target

New extension: CRYPT target

[Gervasio Bernal]

Hi all!!!

After some months of development we have finished this new extension.
CRYPT is a new target extension for Netfilter/Iptables that enables the
user to encrypt, decrypt and authenticate any IP protocol traffic using
the Linux Cryptographic API.

For example, if you want to encrypt active FTP (TCP) traffic between
host A and host B, you can do as follows:

(on host A, 1.2.3.4, FTP client)
# iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
# iptables -t mangle -A PREROUTING -s 1.2.3.5 -p 206 -j CRYPT --cipher
3des --key topsecretkeyinascii12345 --mode cbc --direction decrypt

(on host B, 1.2.3.5, FTP server)
# iptables -t mangle -A POSTROUTING -d 1.2.3.4 -p tcp --sport 20:21 -j
CRYPT --cipher 3des --key topsecretkeyinascii12345 --mode cbc
--direction encrypt
# iptables -t mangle -A PREROUTING -s 1.2.3.4 -p 206 -j CRYPT --cipher
blowfish --key topsecret --mode ecb --direction decrypt

_Note_ the symmetry in the rules. Also note the use of protocol 206
(CRYPT_PROTOCOL) in decryption.

You can download it from:
http://crypt.negocios-sa.com.ar

We hope you can test it and we are open for comments and suggestions.

--
Gervasio Bernal <gervasiobernal(at)gmail(dot)com>
Pedro Deis <pedrakos(at)gmail(dot)com>

New extension: CRYPT target

[Gervasio Bernal]

Hi all!!!

After some months of development we have finished this new extension.
CRYPT is a new target extension for Netfilter/Iptables that enables the
user to encrypt, decrypt and authenticate any IP protocol traffic using
the Linux Cryptographic API.

For example, if you want to encrypt FTP (TOP) traffic between host A and
host B, you can do as follows:

(on host A, 1.2.3.4, FTP client)
# iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
# iptables -t mangle -A PREROUTING -s 1.2.3.5 -p 206 -j CRYPT --cipher
3des --key topsecretkeyinascii12345 --mode cbc --direction decrypt

(on host B, 1.2.3.5, FTP server)
# iptables -t mangle -A POSTROUTING -d 1.2.3.4 -p tcp --sport 20:21 -j
CRYPT --cipher 3des --key topsecretkeyinascii12345 --mode cbc
--direction encrypt
# iptables -t mangle -A PREROUTING -s 1.2.3.4 -p 206 -j CRYPT --cipher
blowfish --key topsecret --mode ecb --direction decrypt

_Note_ the symmetry in the rules. Also note the use of protocol 206
(CRYPT_PROTOCOL) in decryption.

We hope you can test it and we are open for comments and suggestions.

--
Gervasio Bernal <gervasiobernal(at)gmail(dot)com>
Pedro Deis <pedrakos(at)gmail(dot)com>

Re: New extension: CRYPT target

[Carl-Daniel Hailfinger]

Gervasio Bernal wrote:
> (on host A, 1.2.3.4, FTP client)
> # iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
> CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt

Ouch. If anybody runs ps while this iptables command is running, he has
your top secret key.

Does this provide any benefit over IPSEC?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: New extension: CRYPT target

[Gervasio Bernal]

Carl-Daniel Hailfinger wrote:
> Gervasio Bernal wrote:
> 
>>(on host A, 1.2.3.4, FTP client)
>># iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>>CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
> 
> 
> Ouch. If anybody runs ps while this iptables command is running, he has
> your top secret key.
> 
> Does this provide any benefit over IPSEC?
IPSEC/OpenSwan is complicated to use and quite heavy.
CRYPT is truely peer-to-peer. It is compatible with routing daemons. It
allows you to encrypt all the traffic between two endpoints or only
certain type of traffic (ej: only TCP connections). It is extremely easy
to use for an administrator familiarized with Linux firewalling since it
uses Iptables and it does not make any modification to the normal
routing behavior. CRYPT is considerably light and does all the
encryption/decryption process at kernel space (contrary to OpenVPN).

> 
> Regards,
> Carl-Daniel

Re: New extension: CRYPT target

[Carl-Daniel Hailfinger]

Gervasio Bernal wrote:
> Carl-Daniel Hailfinger wrote:
>> Gervasio Bernal wrote:
>>
>>> (on host A, 1.2.3.4, FTP client)
>>> # iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>>> CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
>>
>> Ouch. If anybody runs ps while this iptables command is running, he has
>> your top secret key.

How are you going to prevent that?


>> Does this provide any benefit over IPSEC?

> IPSEC/OpenSwan is complicated to use and quite heavy.

I admit IPSEC is complicated to use, but it has lightweight modes.

> CRYPT is truely peer-to-peer.

IPSEC also has peer-to-peer modes.

> It is compatible with routing daemons.

Same for IPSEC to a certain extent (depends on how you use IPSEC)

> It allows you to encrypt all the traffic between two endpoints or
> only certain type of traffic (ej: only TCP connections).

Same for IPSEC.

> It is extremely easy to use for an administrator familiarized
> with Linux firewalling since it uses Iptables and it

Unfortunately, IPSEC is not so easy to use.

> does not make any modification to the normal routing behavior.

IPSEC can do that in some modes.

> CRYPT is considerably light and does all the
> encryption/decryption process at kernel space (contrary to OpenVPN).

OK, but does it have any advantages over an encryption library loaded
with LD_PRELOAD which replaces all networking functions for a given
application with its own encrypted variant? I consider "all in kernel"
to be a disadvantage.


What happens if a router on the way decides to fragment the packets?


I think your approach to encrypted communication is interesting, but
wouldn't an iptables interface to IPSEC in transport mode achieve
similar results?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: New extension: CRYPT target

[Gervasio Bernal]

Carl-Daniel Hailfinger wrote:
> Gervasio Bernal wrote:
> 
>>Carl-Daniel Hailfinger wrote:
>>
>>>Gervasio Bernal wrote:
>>>
>>>
>>>>(on host A, 1.2.3.4, FTP client)
>>>># iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>>>>CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
>>>
>>>Ouch. If anybody runs ps while this iptables command is running, he has
>>>your top secret key.
> 
> 
> How are you going to prevent that?
Well, give us some time to study it.
> 
> 
> 
>>>Does this provide any benefit over IPSEC?
> 
> 
>>IPSEC/OpenSwan is complicated to use and quite heavy.
> 
> 
> I admit IPSEC is complicated to use, but it has lightweight modes.
> 
> 
>>CRYPT is truely peer-to-peer.
> 
> 
> IPSEC also has peer-to-peer modes.
> 
> 
>>It is compatible with routing daemons.
> 
> 
> Same for IPSEC to a certain extent (depends on how you use IPSEC)
> 
> 
>>It allows you to encrypt all the traffic between two endpoints or
>>only certain type of traffic (ej: only TCP connections).
> 
> 
> Same for IPSEC.
> 
> 
>>It is extremely easy to use for an administrator familiarized
>>with Linux firewalling since it uses Iptables and it
> 
> 
> Unfortunately, IPSEC is not so easy to use.
> 
> 
>>does not make any modification to the normal routing behavior.
> 
> 
> IPSEC can do that in some modes.
> 
> 
>>CRYPT is considerably light and does all the
>>encryption/decryption process at kernel space (contrary to OpenVPN).
> 
> 
> OK, but does it have any advantages over an encryption library loaded
> with LD_PRELOAD which replaces all networking functions for a given
> application with its own encrypted variant? I consider "all in kernel"
> to be a disadvantage.
> 
> 
> What happens if a router on the way decides to fragment the packets?
In TCP connections there is no problem, we use destination MTU to
calculate the corresponding Maximun Segment Size.
In others protocols we are studying the way to avoid fragmentation.

> 
> 
> I think your approach to encrypted communication is interesting, but
> wouldn't an iptables interface to IPSEC in transport mode achieve
> similar results?
Yes, but if you tell to someone that he can encrypt and authenticate a
communication using Iptables only, I think that the extension could
interest to him.

> 
> 
> Regards,
> Carl-Daniel

Re: New extension: CRYPT target

[Gervasio Bernal]

Gervasio Bernal wrote:
> Carl-Daniel Hailfinger wrote:
> 
>>Gervasio Bernal wrote:
>>
>>
>>>Carl-Daniel Hailfinger wrote:
>>>
>>>
>>>>Gervasio Bernal wrote:
>>>>
>>>>
>>>>
>>>>>(on host A, 1.2.3.4, FTP client)
>>>>># iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>>>>>CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
>>>>
>>>>Ouch. If anybody runs ps while this iptables command is running, he has
>>>>your top secret key.
>>
>>
>>How are you going to prevent that?
> 
> Well, give us some time to study it.

One possible solution would be to use a file to store the key, and chmod
that file.That would be correct?

> 
>>
>>
>>>>Does this provide any benefit over IPSEC?
>>
>>
>>>IPSEC/OpenSwan is complicated to use and quite heavy.
>>
>>
>>I admit IPSEC is complicated to use, but it has lightweight modes.
>>
>>
>>
>>>CRYPT is truely peer-to-peer.
>>
>>
>>IPSEC also has peer-to-peer modes.
>>
>>
>>
>>>It is compatible with routing daemons.
>>
>>
>>Same for IPSEC to a certain extent (depends on how you use IPSEC)
>>
>>
>>
>>>It allows you to encrypt all the traffic between two endpoints or
>>>only certain type of traffic (ej: only TCP connections).
>>
>>
>>Same for IPSEC.
>>
>>
>>
>>>It is extremely easy to use for an administrator familiarized
>>>with Linux firewalling since it uses Iptables and it
>>
>>
>>Unfortunately, IPSEC is not so easy to use.
>>
>>
>>
>>>does not make any modification to the normal routing behavior.
>>
>>
>>IPSEC can do that in some modes.
>>
>>
>>
>>>CRYPT is considerably light and does all the
>>>encryption/decryption process at kernel space (contrary to OpenVPN).
>>
>>
>>OK, but does it have any advantages over an encryption library loaded
>>with LD_PRELOAD which replaces all networking functions for a given
>>application with its own encrypted variant? I consider "all in kernel"
>>to be a disadvantage.
>>
>>
>>What happens if a router on the way decides to fragment the packets?
> 
> In TCP connections there is no problem, we use destination MTU to
> calculate the corresponding Maximun Segment Size.
> In others protocols we are studying the way to avoid fragmentation.
> 
> 
>>
>>I think your approach to encrypted communication is interesting, but
>>wouldn't an iptables interface to IPSEC in transport mode achieve
>>similar results?
> 
> Yes, but if you tell to someone that he can encrypt and authenticate a
> communication using Iptables only, I think that the extension could
> interest to him.
> 
> 
>>
>>Regards,
>>Carl-Daniel
> 
> 
> 
> 

Re: New extension: CRYPT target

[Carl-Daniel Hailfinger]

Gervasio Bernal wrote:
> Gervasio Bernal wrote:
>> Carl-Daniel Hailfinger wrote:
>>
>>> Gervasio Bernal wrote:
>>>
>>>
>>>> Carl-Daniel Hailfinger wrote:
>>>>
>>>>
>>>>> Gervasio Bernal wrote:
>>>>>
>>>>>
>>>>>
>>>>>> (on host A, 1.2.3.4, FTP client)
>>>>>> # iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>>>>>> CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
>>>>> Ouch. If anybody runs ps while this iptables command is running, he has
>>>>> your top secret key.
>>>
>>> How are you going to prevent that?
>> Well, give us some time to study it.
> 
> One possible solution would be to use a file to store the key, and chmod
> that file.That would be correct?

No. Still leaves a race. You have to chmod the file before you store the
key in it. Then it would be ok.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: New extension: CRYPT target

[Patrick McHardy]

Carl-Daniel Hailfinger wrote:
> Gervasio Bernal wrote:
>
>>One possible solution would be to use a file to store the key, and chmod
>>that file.That would be correct?
> 
> 
> No. Still leaves a race. You have to chmod the file before you store the
> key in it. Then it would be ok.

You are both very wrong :) What prevents someone from opening it
before the chmod, and read it afterwards? This is what umask is
for ..

Re: New extension: CRYPT target

[Carl-Daniel Hailfinger]

Patrick McHardy wrote:
> Carl-Daniel Hailfinger wrote:
>> Gervasio Bernal wrote:
>>
>>> One possible solution would be to use a file to store the key, and chmod
>>> that file.That would be correct?
>>
>> No. Still leaves a race. You have to chmod the file before you store the
>> key in it. Then it would be ok.
> 
> You are both very wrong :) What prevents someone from opening it
> before the chmod, and read it afterwards? This is what umask is
> for ..

umask alone won't help. If an attacker creates a file with the same
name in the same place before you open it and has that file open
before you write to it, he will still win. Correct umask and
opening it with O_CREAT|O_EXCL should mostly be safe, though.
I assume you want to do all this stuff as root. If /root is
only readable by root, create the file there and you should be
safe.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: New extension: CRYPT target

[Gervasio Bernal]

Carl-Daniel Hailfinger wrote:
> Patrick McHardy wrote:
> 
>>Carl-Daniel Hailfinger wrote:
>>
>>>Gervasio Bernal wrote:
>>>
>>>
>>>>One possible solution would be to use a file to store the key, and chmod
>>>>that file.That would be correct?
>>>
>>>No. Still leaves a race. You have to chmod the file before you store the
>>>key in it. Then it would be ok.
>>
>>You are both very wrong :) What prevents someone from opening it
>>before the chmod, and read it afterwards? This is what umask is
>>for ..
> 
> 
> umask alone won't help. If an attacker creates a file with the same
> name in the same place before you open it and has that file open
> before you write to it, he will still win. Correct umask and
> opening it with O_CREAT|O_EXCL should mostly be safe, though.
> I assume you want to do all this stuff as root. If /root is
> only readable by root, create the file there and you should be
> safe.
> 

The idea of using a file is like this:
1- Being root, create a file called /root/file1.key
#touch /root/file1.key
#ls -al /root/file1.key
-rw-r--r--  1 root root 0 May 23 20:05 file1.key

2- Change permissions
#chmod 600 /root/file1.key
#ls -al /root/file1.key
-rw-------  1 root root 0 May 23 20:05 file1.key

3- Open /root/file1.key and add a key

4- Use file1.key in CRYPT extension
#iptables -t mangle -A PREROUTING -p 206 -j CRYPT --cipher aes --mode
cbc --fkey /root/file1.key --direction decrypt
Where fkey is an argument that receives the key file to use.

> Regards,
> Carl-Daniel

Re: New extension: CRYPT target

[Patrick Schaaf]

> The idea of using a file is like this:
> 1- Being root, create a file called /root/file1.key
> #touch /root/file1.key
> #ls -al /root/file1.key
> -rw-r--r--  1 root root 0 May 23 20:05 file1.key

Now the attacker can open the file (if they have permission to read
that directory, but I'm sure you didn't want to know that...)

> 2- Change permissions
> #chmod 600 /root/file1.key
> #ls -al /root/file1.key
> -rw-------  1 root root 0 May 23 20:05 file1.key

The attacker keeps the file open; this does not change anything.

> 3- Open /root/file1.key and add a key

And now the attacker can read the key from the still open file.

You should try to understand what people here are telling you.

best regards
  Patrick

Re: New extension: CRYPT target

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


uhm, the absolutely correct answer is that you have to input the key via
netlink, not via system(). call. 

The lack of a modular netlink interface to netfilter is what prevents
this.

Failing that, need to provide the key on a pipe. Perhaps have fd#3 be
open for the module to read it from the key management application.

However, in general, you don't really want to tie the iptables policy to
the keying system. You want to be able to rekey the cipher keys
independant of the policy. 

I would, btw, remove ecb mode completely. Don't even make it an
option.  It has essentially no value, and it is a code path that you
will have to test.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRHNT4YCLcPvd0N1lAQJVGAgAvdz1pRShuuBdme/LcVfFCtbeB1EVka22
FE7VM4vqIm5LS/wJRBRU8255LG3eebiJGihgQfm+QG4OIt6nuBEyuXW64dNP4pyU
W4kt2WvM0S1zWh9iUeJ5e3RA9PvMr9S2TWCenVI1GazTnly6x701lkwEsi86gFyy
isFfQctvunDl55F/A5Q40gzRBAxoBuXlPtOcs7lKazjwP9QjHpf7KtR32b3EVdCz
mIlmIz7HVgueoJglXQNEnpn/5M9gvblRDHxmdfsugWaE3le+4VUhY7esMkdowkoT
2AdIk4phonoUkisLM+wWf8uss8e1sTmmj4QNZWcZpoeKFo4YnnktZw==
=KiuX
-----END PGP SIGNATURE-----

Re: New extension: CRYPT target

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Gervasio" == Gervasio Bernal <gervasiobernal@speedy.com.ar> writes:
    Gervasio> Carl-Daniel Hailfinger wrote:
    >> Gervasio Bernal wrote:
    >> 
    >>> (on host A, 1.2.3.4, FTP client) # iptables -t mangle -A
    >>> POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j CRYPT --cipher
    >>> blowfish --key topsecret --mode ecb --direction encrypt
    >> 
    >> 
    >> Ouch. If anybody runs ps while this iptables command is running,
    >> he has your top secret key.
    >> 
    >> Does this provide any benefit over IPSEC?
    Gervasio> IPSEC/OpenSwan is complicated to use and quite heavy.
  
  Have you tried?
  It is not heavy. Your solution is generally rather incomplete, since
it seems to lack any configuration file, policy system, or automatic key
management. 

  It is only complicated if you have been mislead into assuming that you
need a certificate. (ipsec-tools' racoon is guilty in that regard)

    Gervasio> CRYPT is truely peer-to-peer. It is compatible with
    Gervasio> routing daemons. It allows you to encrypt all the traffic
    Gervasio> between two endpoints or only certain type of traffic (ej:
    Gervasio> only TCP connections). It is extremely easy to use for an

  I do exactly that regularly.

    Gervasio> administrator familiarized with Linux firewalling since it
    Gervasio> uses Iptables and it does not make any modification to the
    Gervasio> normal routing behavior. CRYPT is considerably light and

  We have patches that permit you to decide what to encrypt using
iptables. 

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRHDwY4CLcPvd0N1lAQI1Mwf/XpEika5C4N2GVLtLg1MEuXoQ+Sy5qKjX
KloJjQKnHPbz24sHJ6/80DtmXD4HmfaIfaDkjstgjxqEdoA0YR5MgwPgeucLhGVn
INXnTBrCHKamqMmI0I+RoH2pHbxNmtd1C849FF0gwzD//vwKqaIaVjxqkyXn1d6B
MMkPZwcnSY+NIDIab2O5Ycm0A5LfLTAsO8+MDxpP5LItjtAkT3Ur8AJdFgC8afwu
wnjFVzfZ/v2Rlgrolf6+0wH7VNVCkMcoiPp+DUmU5EhXyLMRvYzq8HwIcJLNgaGm
pP11DUKI8fAckx8APWmCSbmrR6MQFCmYeY8bTcr+D/kNJXJfkvJB+Q==
=eCAB
-----END PGP SIGNATURE-----

Re: New extension: CRYPT target

[Gervasio Bernal]

Michael Richardson wrote:
> 
> 
>>>>>>>"Gervasio" == Gervasio Bernal <gervasiobernal@speedy.com.ar> writes:
> 
>     Gervasio> Carl-Daniel Hailfinger wrote:
>     >> Gervasio Bernal wrote:
>     >> 
>     >>> (on host A, 1.2.3.4, FTP client) # iptables -t mangle -A
>     >>> POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j CRYPT --cipher
>     >>> blowfish --key topsecret --mode ecb --direction encrypt
>     >> 
>     >> 
>     >> Ouch. If anybody runs ps while this iptables command is running,
>     >> he has your top secret key.
>     >> 
>     >> Does this provide any benefit over IPSEC?
>     Gervasio> IPSEC/OpenSwan is complicated to use and quite heavy.
>   
>   Have you tried?
>   It is not heavy. Your solution is generally rather incomplete, since
> it seems to lack any configuration file, policy system, or automatic key
> management. 

The idea behind CRYPT extension is not to replace IPSEC absolutely, but
to be a simple alternative of use for encryption/decryption and packet
authentication using Iptables. It could be useful for somebody.

We have also developed a module in Python that use the CRYPT extension,
configuration files, has automatic key management and user
authentication using certificates. But we need that someone else can
test first the extension alone, and comments its experience to us.

> 
>   It is only complicated if you have been mislead into assuming that you
> need a certificate. (ipsec-tools' racoon is guilty in that regard)
> 
>     Gervasio> CRYPT is truely peer-to-peer. It is compatible with
>     Gervasio> routing daemons. It allows you to encrypt all the traffic
>     Gervasio> between two endpoints or only certain type of traffic (ej:
>     Gervasio> only TCP connections). It is extremely easy to use for an
> 
>   I do exactly that regularly.
> 
>     Gervasio> administrator familiarized with Linux firewalling since it
>     Gervasio> uses Iptables and it does not make any modification to the
>     Gervasio> normal routing behavior. CRYPT is considerably light and
> 
>   We have patches that permit you to decide what to encrypt using
> iptables. 
> 

Re: New extension: CRYPT target

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Gervasio" == Gervasio Bernal <gervasiobernal@speedy.com.ar> writes:
    Gervasio> The idea behind CRYPT extension is not to replace IPSEC
    Gervasio> absolutely, but to be a simple alternative of use for
    Gervasio> encryption/decryption and packet authentication using
    Gervasio> Iptables. It could be useful for somebody.

  Tell me the threat model.

  Under what circumstances is it better than:
	a) IPsec with OE (with is dirty simple to configure)
	b) TLS/SSL LD_PRELOAD wrapper
	c) using SCP instead of FTP (or rsync over SSH)
	d) OpenVPN or SSH port forwarding
	e) HIP

    Gervasio> We have also developed a module in Python that use the
    Gervasio> CRYPT extension, configuration files, has automatic key
    Gervasio> management and user authentication using certificates. But
    Gervasio> we need that someone else can test first the extension
    Gervasio> alone, and comments its experience to us.

  Why in the world would you build such a complicated system? 
  You just told us that you wanted something simpler than IPsec.

  It seems like vanity crypto to me.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRHMJYICLcPvd0N1lAQIdDAf/bMGdfP6zIJ39lGgduUbfYmx7QEX5EwC7
4tK+Px3Lk4z8P1nowLyCLHUL11YXn6t+WfaPGc/Gp9jvVd0r1R0UXOSuiQ4b3bSy
kcdalGLMAe9XEusecIfEqdhHm+xu8311eGSN1Q2fJbajPy0D1w9dATSY51BWgKU6
0+Pm6YHTQzYOYZOMTzlx4BYZbanrpYXgS+klm3liE10VcB4JtOD4/w9D69kYEm6R
ajDacRC8Hjp068JeKEbr/DJegxBLf/Rkt/GepRoiwQea2kYN8/E8ZAMuYjqafL2b
S49KUwjIHVac+Gad9Y0MJquVvdp+QmST/o/JWcCVJoyLB1yL2znDMw==
=lCRN
-----END PGP SIGNATURE-----

Re: New extension: CRYPT target

[Gervasio Bernal]

Michael Richardson wrote:
> 
> 
>>>>>>>"Gervasio" == Gervasio Bernal <gervasiobernal@speedy.com.ar> writes:
> 
>     Gervasio> The idea behind CRYPT extension is not to replace IPSEC
>     Gervasio> absolutely, but to be a simple alternative of use for
>     Gervasio> encryption/decryption and packet authentication using
>     Gervasio> Iptables. It could be useful for somebody.
> 
>   Tell me the threat model.
> 
>   Under what circumstances is it better than:
> 	a) IPsec with OE (with is dirty simple to configure)
> 	b) TLS/SSL LD_PRELOAD wrapper
> 	c) using SCP instead of FTP (or rsync over SSH)
> 	d) OpenVPN or SSH port forwarding
> 	e) HIP

Perhaps in none of those circumstances.
CRYPT extension is just an alternative, as well OpenOffice Writer is an
alternative of Microsoft Word. It is good to have several different
alternatives.

> 
>     Gervasio> We have also developed a module in Python that use the
>     Gervasio> CRYPT extension, configuration files, has automatic key
>     Gervasio> management and user authentication using certificates. But
>     Gervasio> we need that someone else can test first the extension
>     Gervasio> alone, and comments its experience to us.
> 
>   Why in the world would you build such a complicated system? 

It is much more easy of which you imagine. You only have to run a Python
application and voila!!

>   You just told us that you wanted something simpler than IPsec.
> 
>   It seems like vanity crypto to me.
> 

Re: New extension: CRYPT target

[Martijn Lievaart]

Gervasio Bernal wrote:

>Hi all!!!
>
>After some months of development we have finished this new extension.
>CRYPT is a new target extension for Netfilter/Iptables that enables the
>user to encrypt, decrypt and authenticate any IP protocol traffic using
>the Linux Cryptographic API.
>
>For example, if you want to encrypt FTP (TOP) traffic between host A and
>host B, you can do as follows:
>
>(on host A, 1.2.3.4, FTP client)
># iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
># iptables -t mangle -A PREROUTING -s 1.2.3.5 -p 206 -j CRYPT --cipher
>3des --key topsecretkeyinascii12345 --mode cbc --direction decrypt
>  
>

Minor critisism, this will not catch the data channels of ftp, only the 
control channel. Active ftp uses a *source* port of 20, passive ftp 
(which is more common nowadays) uses whatever port range the server uses 
for data channels (typically something like 30000-31000).

Does -mode cbc use the iv from the last packet? If not, this seems like 
a false sense of security. Protocols that use lots of small packets will 
still more or less have the drawbacks of ecb.

M4

Re: New extension: CRYPT target

[Cedric Blancher]

Le dimanche 21 mai 2006 à 19:51 +0200, Martijn Lievaart a écrit :
> Minor critisism, this will not catch the data channels of ftp, only the 
> control channel. Active ftp uses a *source* port of 20, passive ftp 
> (which is more common nowadays) uses whatever port range the server uses 
> for data channels (typically something like 30000-31000).

You can use helper match, something like -m helper --helper ftp.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: New extension: CRYPT target

[Gervasio Bernal]

Martijn Lievaart wrote:
> Gervasio Bernal wrote:
> 
>> Hi all!!!
>>
>> After some months of development we have finished this new extension.
>> CRYPT is a new target extension for Netfilter/Iptables that enables the
>> user to encrypt, decrypt and authenticate any IP protocol traffic using
>> the Linux Cryptographic API.
>>
>> For example, if you want to encrypt FTP (TOP) traffic between host A and
>> host B, you can do as follows:
>>
>> (on host A, 1.2.3.4, FTP client)
>> # iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
>> CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
>> # iptables -t mangle -A PREROUTING -s 1.2.3.5 -p 206 -j CRYPT --cipher
>> 3des --key topsecretkeyinascii12345 --mode cbc --direction decrypt
>>  
>>
> 
> Minor critisism, this will not catch the data channels of ftp, only the
> control channel. Active ftp uses a *source* port of 20, passive ftp
> (which is more common nowadays) uses whatever port range the server uses
> for data channels (typically something like 30000-31000).
Yes, you are right, it's for an active FTP. It was only an example.

> 
> Does -mode cbc use the iv from the last packet? 
The IV (Initialization Vector) is calculated in every packet with
get_random_bytes function.

> If not, this seems like
> a false sense of security. Protocols that use lots of small packets will
> still more or less have the drawbacks of ecb.


> 
> M4
> 
> 
> 
> 
> 

Re: New extension: CRYPT target

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Martijn" == Martijn Lievaart <m@rtij.nl> writes:
    Martijn> Does -mode cbc use the iv from the last packet? If not,

  That method, which IPsec has suggested for awhile, turns out to be 
less than ideal. 
  see http://www.hut.fi/~svaarala/espiv.pdf

  Well, that URL is no longer valid... try:

   http://www.samivaarala.com/publications/espiv_final.pdf

    Martijn> this seems like a false sense of security. Protocols that
    Martijn> use lots of small packets will still more or less have the
    Martijn> drawbacks of ecb.

  ecb mode is just not useful.
  If you want network encryption, use it: it's called IPsec.

  If you want snake oil, then I guess this is the code for you.

  I recommend against including this functionality.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRHDvm4CLcPvd0N1lAQIPFgf+N9Vpe+9FpjmCcZKw708ja1vp5MmjRP8k
sQKOsjiwGe37/0u7g4wlX5SsAZ5ns9lloWZUWV65z+QeMal/2eBZb90H+E9cpjYy
4XKqBwUe3C9Oe6iJywL6FVY/4Q/VQ2nJhhei5s65MwTynevJ4oTAbUSF2yVqlSbM
YR5t+QMnXYVRkX8TmOKG51hTtC+PTp24RL/Gvl0QL/BPBubojGYnxY/P0X9m1i7y
jfhtwFmI352NsQJuqWXizHgcE39nj69ycpPT2FWf5FoXVR73cTg/+zfRZ6wHcx7U
360SUkwPfY2VUg/l0lpQDPSCOQV8heJqp1MgG+8Nn7dS54VEbwl0KQ==
=/0uZ
-----END PGP SIGNATURE-----

Re: New extension: CRYPT target

[Gervasio Bernal]

Gervasio Bernal wrote:
> Hi all!!!
> 
> After some months of development we have finished this new extension.
> CRYPT is a new target extension for Netfilter/Iptables that enables the
> user to encrypt, decrypt and authenticate any IP protocol traffic using
> the Linux Cryptographic API.
> 
> For example, if you want to encrypt FTP (TOP) traffic between host A and
> host B, you can do as follows:
> 
> (on host A, 1.2.3.4, FTP client)
> # iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j
> CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt
> # iptables -t mangle -A PREROUTING -s 1.2.3.5 -p 206 -j CRYPT --cipher
> 3des --key topsecretkeyinascii12345 --mode cbc --direction decrypt
> 
> (on host B, 1.2.3.5, FTP server)
> # iptables -t mangle -A POSTROUTING -d 1.2.3.4 -p tcp --sport 20:21 -j
> CRYPT --cipher 3des --key topsecretkeyinascii12345 --mode cbc
> --direction encrypt
> # iptables -t mangle -A PREROUTING -s 1.2.3.4 -p 206 -j CRYPT --cipher
> blowfish --key topsecret --mode ecb --direction decrypt
> 
> _Note_ the symmetry in the rules. Also note the use of protocol 206
> (CRYPT_PROTOCOL) in decryption.
> 
> We hope you can test it and we are open for comments and suggestions.
> 
Upsss! We forget to post the URL where you can download it:
http://crypt.negocios-sa.com.ar

> --
> Gervasio Bernal <gervasiobernal(at)gmail(dot)com>
> Pedro Deis <pedrakos(at)gmail(dot)com>
> 
> 

Re: New extension: CRYPT target

[Lennart Poettering]

On Sun, 21.05.06 15:59, Gervasio Bernal (gervasiobernal@speedy.com.ar) wrote:

> Hi all!!!

Hi!

> After some months of development we have finished this new extension.
> CRYPT is a new target extension for Netfilter/Iptables that enables the
> user to encrypt, decrypt and authenticate any IP protocol traffic using
> the Linux Cryptographic API.

[...]

I wonder if you are aware that I wrote exactly the same thing a few
years ago?

http://0pointer.de/lennart/projects/seppl/

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/

Re: New extension: CRYPT target

[Gervasio Bernal]

Lennart Poettering wrote:
> On Sun, 21.05.06 15:59, Gervasio Bernal (gervasiobernal@speedy.com.ar) wrote:
> 
> 
>>Hi all!!!
> 
> 
> Hi!
> 
> 
>>After some months of development we have finished this new extension.
>>CRYPT is a new target extension for Netfilter/Iptables that enables the
>>user to encrypt, decrypt and authenticate any IP protocol traffic using
>>the Linux Cryptographic API.
> 
> 
> [...]
> 
> I wonder if you are aware that I wrote exactly the same thing a few
> years ago?

Yes, while we were looking for information for our extension we found
your web site, but as we were about to finish it, we decided to continue
doing it. Each job, yours and our, have interesting features, that the
other one doesn't have. It would be good to unify them and obtain
something more robust.
It would be also fantastic that the extension someday (of course there
is much to debug) could be included in Iptables core.

I think the idea of encryption using Iptables is really great!

> 
> http://0pointer.de/lennart/projects/seppl/
> 
> Lennart
> 

Re: New extension: CRYPT target

[Patrick McHardy]

Gervasio Bernal wrote:
> I think the idea of encryption using Iptables is really great!

The thing I don't get: what advantages does it have over using
IPsec with manual keying (forgetting about the selector, once
nfmark is supported this point won't matter)?