Mailing List Archive

Securing portage --- an OpenBSD approach
The recent discussion on how to protect the portage tree from
man-in-the-middle attacks has concentrated on signing either the portage
tarball or the individual files in the tree.

What about approaching the problem the way OpenBSD deals with its ports,
that is with cvs over an ssh tunnel to authorized mirrors. The only
drawback I see is that many gentoo users use rsync, but the cvs approach
could be added on top of what already exists and security conscious users
will then have the option of switching.

-------------------------------------------------------------------

Anthony G. Basile, Ph.D.
Director of Information Technology,
D'Youville College,
320 Porter Ave.
Buffalo NY, 14201

Work: (716) 829-8197 (voicemail)


--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Friday 12 November 2004 13:54, dante@virtualblueness.net wrote:
> The recent discussion on how to protect the portage tree from
> man-in-the-middle attacks has concentrated on signing either the
> portage tarball or the individual files in the tree.
>
> What about approaching the problem the way OpenBSD deals with its
> ports, that is with cvs over an ssh tunnel to authorized mirrors. The
> only drawback I see is that many gentoo users use rsync, but the cvs
> approach could be added on top of what already exists and security
> conscious users will then have the option of switching.

In the early days, gentoo did actually offer anonymous cvs. It was quickly
removed as putting a too big load on the servers. I don't know whether we
can devise a way in which we can offer an acceptable level of anon cvs.
In between I do think that we might want to set up secure rsync (ssh or
stunnel) at least from the master rsync mirror to the normal mirrors, and
maybe even allow normal users to use "secure rsync". Setting up ssl rsync
should not be hard, allthough rsync does not by itself support it out of
the box. Stunnel should be able to offer it.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Fri, Nov 12, 2004 at 07:54:38AM -0500, dante@virtualblueness.net wrote:
>
> The recent discussion on how to protect the portage tree from
> man-in-the-middle attacks has concentrated on signing either the portage
> tarball or the individual files in the tree.
>
> What about approaching the problem the way OpenBSD deals with its ports,
> that is with cvs over an ssh tunnel to authorized mirrors. The only
> drawback I see is that many gentoo users use rsync, but the cvs approach
> could be added on top of what already exists and security conscious users
> will then have the option of switching.

Do you know how the mirrors are authorized? Official certificates, selfsigned,
own pki?
I think if the rsync mirrors are too stressed for signation, they would be
too stressed for rsync too, allthough rsync could be tunneled too.

Anyway interesting approuch too.

regards klaus

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Fri, Nov 12, 2004 at 02:14:39PM +0100, Klaus Wagner wrote:
>
> Do you know how the mirrors are authorized? Official certificates, selfsigned,
> own pki?
> I think if the rsync mirrors are too stressed for signation, they would be
> too stressed for rsync too, allthough rsync could be tunneled too.
i meant to stressed for encryption too (ssl tunneling)
>
> Anyway interesting approuch too.
>
> regards klaus
>
> --
> gentoo-security@gentoo.org mailing list
>
>

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Klaus Wagner wrote:
> I think if the rsync mirrors are too stressed for signation, they would be
> too stressed for rsync too, allthough rsync could be tunneled too.

One of the suggestions we were kicking around was to use Stunnel to
encrypt rsync over SSL. This, of course, fails to be as encompassing as
the Final Solution involving GPG, but is suitable as a stopgap. We
rejected it because of concern about server load on the mirrors,
actually, since SSL does introduce some significant CPU overhead.

Not running the mirrors myself, I can't really give you any figures. But
GPG signing introduces no CPU load and minimal extra amounts of data, so
is, from the infrastructure standpoint, the least likely to cause things
to fall over.
- --
Dan "KrispyKringle" Margolis
Security Coordinator/Audit Project, Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQZTQgbDO2aFJ9pv2AQIrcQf/cLcB1Eu/HgsxLnXNTPsc1NyWJ2cQVT+w
uCXw3xMwmaKhZFxG/W3ow6r8h+DPV3Cs69s+UjUiwA4TAGQejo/UaQuq1a8i3ZJp
WLFyg+M4wkrIO0Op26EIOPF5bofVbdL3LoK2PaGqWHTIoy6KGawBda3PBt0LpCKm
SFi9Y+hwPiiQkzfDrLlMcMem7vBOvIw4MrqZvqA12GLu9kQ9bu4it94RnlbsHWc1
1R7Yicc42L15GBKwenngKTlsHfTpUGcUBTaRVKL2OhoywTlq2Wwg6GYXkqbgvI5h
z9DVTdM05BhK1GJ60j7fDLv47l/H/NCmupp3k/GXcjfyFOVpUu5Weg==
=c+h1
-----END PGP SIGNATURE-----

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Friday 12 November 2004 09:02 am, Dan Margolis wrote:
> Klaus Wagner wrote:
> > I think if the rsync mirrors are too stressed for signation, they would
> > be too stressed for rsync too, allthough rsync could be tunneled too.
>
> One of the suggestions we were kicking around was to use Stunnel to
> encrypt rsync over SSL. This, of course, fails to be as encompassing as
> the Final Solution involving GPG, but is suitable as a stopgap. We
> rejected it because of concern about server load on the mirrors,
> actually, since SSL does introduce some significant CPU overhead.

wouldn't public-key rsync over ssh be a lower CPU load option than rsync over
SSL? This option would also be suitable as a 'secure rsync' method for
remote users, if you wanted to push it out that far. I can see how CPU load
for remote users to tunnel rsync over SSL or ssh, but the connection between
the Gentoo rsync master and the mirrors could be secured this way.

Regards,

- Brian

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Fri, Nov 12, 2004 at 09:54:11AM -0600, Brian G. Peterson wrote:
>
> wouldn't public-key rsync over ssh be a lower CPU load option than rsync over
> SSL?

I don't think so, because internally ssh is using ssl. In both variants,
rsync is generating a list of files and timestamps (maybe hashes too?),
exchanges this over an encrypted connection (in both cases an ssl cipher)
and finally transfers the files over an encrypted connection(tunneled by ssh or by stunnel).

ssh (at least in newer versions) is using very strong ciphers by default,
which stress the cpu even more (AES 256 or better).

regards
klaus

ps. are there any plans for having a https site for gentoo, or
the webservers, where the snapshots are put onto?

>This option would also be suitable as a 'secure rsync' method for
> remote users, if you wanted to push it out that far. I can see how CPU load
> for remote users to tunnel rsync over SSL or ssh, but the connection between
> the Gentoo rsync master and the mirrors could be secured this way.
>
> Regards,
>
> - Brian

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
as opposed to Stunnel , won't a simple 'rsync -e ssh' suffice?
those who want to can use ssh, others can use the default, rsh
<shudders>
or, if you start the server with one, will it not respond to the other?

james

On Nov 12, 2004, at 8:08 AM, Paul de Vrieze wrote:

> On Friday 12 November 2004 13:54, dante@virtualblueness.net wrote:
>> The recent discussion on how to protect the portage tree from
>> man-in-the-middle attacks has concentrated on signing either the
>> portage tarball or the individual files in the tree.
>>
>> What about approaching the problem the way OpenBSD deals with its
>> ports, that is with cvs over an ssh tunnel to authorized mirrors. The
>> only drawback I see is that many gentoo users use rsync, but the cvs
>> approach could be added on top of what already exists and security
>> conscious users will then have the option of switching.
>
> In the early days, gentoo did actually offer anonymous cvs. It was
> quickly
> removed as putting a too big load on the servers. I don't know whether
> we
> can devise a way in which we can offer an acceptable level of anon cvs.
> In between I do think that we might want to set up secure rsync (ssh or
> stunnel) at least from the master rsync mirror to the normal mirrors,
> and
> maybe even allow normal users to use "secure rsync". Setting up ssl
> rsync
> should not be hard, allthough rsync does not by itself support it out
> of
> the box. Stunnel should be able to offer it.
>
> Paul
>
> --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@gentoo.org
> Homepage: http://www.devrieze.net


--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Fri, Nov 12, 2004 at 05:16:24PM +0100, Klaus Wagner wrote:
> ps. are there any plans for having a https site for gentoo, or
> the webservers, where the snapshots are put onto?

While I'm not opposed to ssl/ssh links in any way, I think this would be
more work to install than the signature method that already has a patch.

Consider:

Patch method:
- no mirror needs to be updated
- users can continue to use any available mirrors for
the webrsync tar (do they exist?)
- the main gentoo server only has to serve the signature
(this could be put on a single mirror too, point being
that the signature doesn't have to be on every mirror
to be effective)

SSL/SSH method:
- either every mirror needs to support it
- or anyone who is concerned, suddenly stops using mirrors
and switches to the main server
- doesn't detect cases where a mirror is compromised

Just points to be aware of when considering SSL/SSH.

- Chris


--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Fri, Nov 12, 2004 at 05:16:24PM +0100 or thereabouts, Klaus Wagner wrote:
> ps. are there any plans for having a https site for gentoo, or
> the webservers, where the snapshots are put onto?

No -- we have very little control over our community mirrors, which is why
we made a decision to go the other way and assume all the distribution
points are untrusted. That's why things are (or at least will be) signed
by developers before they're uploaded to CVS.

--kurt
Re: Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Fri, Nov 12, 2004 at 11:30:08AM -0500, Chris Frey wrote:
> While I'm not opposed to ssl/ssh links in any way, I think this would be
> more work to install than the signature method that already has a patch.
>
> Consider:
>
> Patch method:
> - no mirror needs to be updated
> - users can continue to use any available mirrors for
> the webrsync tar (do they exist?)
> - the main gentoo server only has to serve the signature
> (this could be put on a single mirror too, point being
> that the signature doesn't have to be on every mirror
> to be effective)
>
> SSL/SSH method:
> - either every mirror needs to support it
> - or anyone who is concerned, suddenly stops using mirrors
> and switches to the main server
> - doesn't detect cases where a mirror is compromised
>
> Just points to be aware of when considering SSL/SSH.
FullACK

even worse, it would stress, the CPU even more, and so on.

these "solutions" do not interfere with each other but
if these are combined I can't see a great benefit
either.

the only benefit is, that a man in the middle would not
be able to guess the state, my local system is in (eg: if
I am fetching an actual .ebuild file of portage, the mim
can be sure that the local version is not the actual one)
not a big benefit.

anyway, as someone seems to use some sort of that "solution"
I got curious and wanted to get some more details...

regards,

klaus

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Friday 12 November 2004 10:16 am, Klaus Wagner wrote:
> On Fri, Nov 12, 2004 at 09:54:11AM -0600, Brian G. Peterson wrote:
> > wouldn't public-key rsync over ssh be a lower CPU load option than rsync
> > over SSL?
>
> I don't think so, because internally ssh is using ssl.

No, ssh and SSL are two distinct protocols. ssh encrypts its packets directly,
using a variety of algorithms, some of which (the session encryption
algorithms) overlap with SSL, but the *protocol* and *packet layout* are
quite different.

> (in both cases an ssl cipher)

As I said, these are not SSL ciphers, but simply encryption algorithms that
are independent of any particular protocol that uses them.

In my experience, ssh implementations are much more CPU-efficient than OpenSSL
is when usign the same algorithms.

> ssh (at least in newer versions) is using very strong ciphers by default,
> which stress the cpu even more (AES 256 or better).

SSH uses a two-factor encryption approach, the authentication phase uses a
password or a public/private key pair to establish the trust relationship and
to exchange a session key. The session key can be done using any number of
algorithms, AES is common, but there are many more, several of them faster
than AES. The *server* decides which algorithms and the strength of the
algorithm to offer. For use in securing communications with the mirror, even
a very small (56 bit) key would be fine, becasue the *data* is essentially
public, not confidential, and you only need to protect it in transit between
the two servers. Even a 56 bit key can't be broken via brute force quickly
enough for use in a man-in-the middle attack.

The only thing we need to do here is make sure that the data is not tampered
with in transit, if man in the middle attack is the concern.

Regards,

- Brian

--
gentoo-security@gentoo.org mailing list
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Friday 12 November 2004 17:16, James Larkby-Lahet wrote:
> as opposed to Stunnel , won't a simple 'rsync -e ssh' suffice?
> those who want to can use ssh, others can use the default, rsh
> <shudders>
> or, if you start the server with one, will it not respond to the other?

I don't think that you actually want to offer an account to all users of the
mirror. Also current rsync does not use rsh, but uses the rsync server. The
use of ssl (stunnel) is ortogonal to that, ssh is ortogonal to rsh.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
Re: Securing portage --- an OpenBSD approach [ In reply to ]
On Friday 12 November 2004 16:54, Brian G. Peterson wrote:
> On Friday 12 November 2004 09:02 am, Dan Margolis wrote:
> > Klaus Wagner wrote:
> > > I think if the rsync mirrors are too stressed for signation, they would
> > > be too stressed for rsync too, allthough rsync could be tunneled too.
> >
> > One of the suggestions we were kicking around was to use Stunnel to
> > encrypt rsync over SSL. This, of course, fails to be as encompassing as
> > the Final Solution involving GPG, but is suitable as a stopgap. We
> > rejected it because of concern about server load on the mirrors,
> > actually, since SSL does introduce some significant CPU overhead.
>
> wouldn't public-key rsync over ssh be a lower CPU load option than rsync
> over SSL? This option would also be suitable as a 'secure rsync' method
> for remote users, if you wanted to push it out that far. I can see how CPU
> load for remote users to tunnel rsync over SSL or ssh, but the connection
> between the Gentoo rsync master and the mirrors could be secured this way.

The difference between ssh and ssl is very minimal in terms of performance,
however ssl focusses on public services with public certificates, while ssh
focusses on authenticated shell access to known users. The load difference
should be minimal anyway, but ssh is not suitable for the public rsync
service, for inter-mirror rsync it would be acceptable.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net