Bug 475337 - insecure aggressive mode is preferred against more secure main mode in generated configuration
insecure aggressive mode is preferred against more secure main mode in genera...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ipsec-tools (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
: 497554 (view as bug list)
Depends On: 201853
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-08 16:57 EST by Bill Nottingham
Modified: 2014-03-16 23:16 EDT (History)
5 users (show)

See Also:
Fixed In Version: ipsec-tools-0.8.0-4.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-26 10:55:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Updated patch against rawhide (initscripts-8.95.1) (1.76 KB, patch)
2009-07-17 06:02 EDT, Patrick Monnerat
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2008-12-08 16:57:52 EST
+++ This bug was initially created as a clone of Bug #201853 +++

Description of problem:

By ifup-ipsec created peer configuration, insecure aggressive mode is preferred
against more secure main mode.

Version-Release number of selected component (if applicable):
ipsec-tools-0.3.3-6.rhel4.1 (RHEL)
ipsec-tools-0.6.4-1.1 (FC5)

How reproducible:
Always


Steps to Reproduce:
1. Create /etc/sysconfig/network-scripts/ifcfg-ipsec0 like

SRC=192.0.2.1
DST=192.0.2.2
TYPE=IPSEC

IKE_METHOD=PSK
IKE_PSK=secret

2. ifup ipsec0



Actual results:

remote 192.0.2.2
{
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}



Expected results:

remote 192.0.2.2
{
        exchange_mode main, aggressive;
...

Additional info:

Any good reason why the order is "aggressive, main"?

If 2 hosts now using the same setup scripts (e.g. both are RH powered),
aggressive mode would be used.


Also it would be good if this can be controlled by a configuration parameter, e.g.

IKE_MODE=aggressive|main|any

--- Additional comment from pb@bieringer.de on 2006-08-09 11:45:55 EDT ---

BTW: would be great if other parameters would also be optionally configurable, e.g.
 - dh_group (2 = 1024 is also not so secure than upper ones).
 - lifetime

Note also that for automatic keying, neither AH nor ESP can be selected for
phase 2 (IPsec negotiation) and will always default to "sha1" and "3des-cbc"

Topology part is completly missing in configuration like:

# host-to-host
sainfo address 192.0.1.1 any address 192.0.1.2 any
{
        lifetime time 1 hour;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5 ;
        compression_algorithm deflate ;
}


--- Additional comment from notting@redhat.com on 2006-08-09 11:48:26 EDT ---

It's done to decrease connection overhead; I can see making it a configuration
parameter. However, I suspect the more complex of an ipsec configuration you
have, the more likely it is that you should just edit raccoon.conf directly.

--- Additional comment from pb@bieringer.de on 2006-08-09 11:55:22 EDT ---

Hmm, at least phase 2 should be supported in some way. Problem is, if I apply
changes to the file 192.0.2.1.conf directly, they are overwritten, if
ifcfg-ipsec0 is changed.

And if I setup my own racoon.conf file, I run into the problem, that there is no
standalone start script provided for racoon - and as I had to learn from
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136901 this is a feature
and not a bug...

--- Additional comment from pb@bieringer.de on 2006-08-10 05:48:53 EDT ---

Created an attachment (id=133921)
patch which adds support for some more IPsec parameters

Following variables are now supported (and shown with an example):

IKE_EXCHANGE_MODE=main
IKE_DH_GROUP=5
IPSEC_ESP_PROTO=aes128
IPSEC_AH_PROTO=hmac_sha1
IPSEC_LIFETIME="1 hour"
IPSEC_PFS_GROUP=5


--- Additional comment from pb@bieringer.de on 2006-08-10 05:59:50 EDT ---

Some forgotten comments:
- patch is successfully tested in host-to-host mode, can't currently test for
net-to-net mode

- patch cotains also a fix that prevents creation of dedicated conf file with
standard umask permissions 0644, it reduces this to 0600 like racoon.conf has set

- if no of the new introduced parameters are given, still a topology would be
created. This was shown as compatible here to a still unpatched ifup-ipsec file.
But for clean backward compatibility, I will now provide a new version which
explictly only creates topology, if one or more new introduced IPSEC* parameters
are given.

--- Additional comment from pb@bieringer.de on 2006-08-10 06:01:04 EDT ---

Created an attachment (id=133924)
patch which adds support for some more IPsec parameters #2


--- Additional comment from notting@redhat.com on 2008-12-08 16:56:45 EDT ---

This is unlikely to change for RHEL 4 at this point. I'm cloning this bug for the development stream.
Comment 1 iarly selbir 2009-04-04 14:46:25 EDT
Bill, was it solved?

I will go to change it to Assigned, I'm not sure that was solved.

Thanks.
Comment 2 Bill Nottingham 2009-04-06 11:24:49 EDT
Has not been applied yet.
Comment 3 Bill Nottingham 2009-04-27 15:03:34 EDT
*** Bug 497554 has been marked as a duplicate of this bug. ***
Comment 4 Bug Zapper 2009-06-09 06:10:45 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Patrick Monnerat 2009-07-17 06:02:28 EDT
Created attachment 354123 [details]
Updated patch against rawhide (initscripts-8.95.1)

*** This problem is not yet resolved in rawhide ***

The attached patch is adapted from the previous one (version 2) for the current script version.
2 fixes to the previous patch have been added:
_ $MODE = 'host' cannot be true: replaced by $MODE = 'transport'
_ In case $MODE = 'tunnel', "sainfo subnet" is used instead of "sainfo address"

I hope it helps
Comment 6 Bug Zapper 2010-04-27 08:29:22 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Bug Zapper 2011-06-02 14:21:36 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Patrick Monnerat 2011-06-14 08:19:19 EDT
I'm deeply disappointed this 30 month old bug (yes, 2.5 years!) is still present (in version 9.30-1), although a patch fixing it has been provided...
Trying to help with this important package feels like a pain in the ass: see
also bugs 498472 and 665378 :-((

Resetting version to rawhide once again.
Comment 9 Bill Nottingham 2011-06-14 14:04:09 EDT
To be completely honest, ipsec-tools support is deprecated in favor of openswan; in that case we work by just having openswan configurations brought up by that package itself, not done through ifcfg files. The likely way forward is to move ifup/ifdown-ipsec to the ipsec-tools package itself.
Comment 10 Patrick Monnerat 2011-06-16 04:59:48 EDT
> ... move ifup/ifdown-ipsec to the ipsec-tools package itself.

Why not, if it can resolve this bug: IMHO, every solution is better than the current stalled situation.
Comment 11 Bill Nottingham 2011-06-21 15:49:25 EDT
Scripts have been moved in rawhide.
Comment 12 Patrick Monnerat 2011-10-24 11:59:48 EDT
... and problem is still not fixed :-(
Comment 13 Tomas Mraz 2012-01-26 10:55:44 EST
Now the main mode is preferred over the aggressive mode.
Comment 14 Patrick Monnerat 2012-12-13 11:13:37 EST
I've just seen it you fixed it. Many thanks :-)

Note You need to log in before you can comment on or make changes to this bug.