From: Greg Scott <GregScott@InfraSupportEtc.com>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] Proposal for reasonably secure GRE tunneling
Date: Sat, 26 Jan 2002 01:53:09 +0000 [thread overview]
Message-ID: <marc-lartc-101200998913833@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101196067320644@msgid-missing>
That would work, and I think I could set up IPSEC with Free S/WAN,
but PPTP is just so much simpler. And those 9x/ME PCs will be out
there for a long time to come.
- Greg
-----Original Message-----
From: Daniel Wittenberg [mailto:daniel-wittenberg@starken.com]
Sent: Friday, January 25, 2002 6:17 PM
To: Greg Scott
Cc: LARTC
Subject: Re: [LARTC] Proposal for reasonably secure GRE tunneling
Why not use encryption keys instead? Because if you substitute crypto
key for password, then you have an IPSec tunnel. Besides, MS is moving
away from PPTP. Take a look at 2k and XP, they have IPSec tunneling, so
that seems to be the right direction to go.
Dan
On Fri, 2002-01-25 at 06:23, Greg Scott wrote:
> After tossing and turning half the night, this idea came into my head:
>
> It's really neat that we can set up GRE tunnels between Linux servers.
> Way cool, and thanks! But lack of any kind of security is a problem.
>
> What if we had a simple way to secure those GRE packets, or at least
> some means for the two VPN servers to authenticate each other?
>
> So this idea popped into my head that seems straightforward to implement.
> What if the system admin created accounts in both VPN servers, call them
> lanagre and lanbgre. It would be up to the system admin to put in strong
> passwords in those accounts. Both sides would each have both accounts,
> and it would be up to the system admins on both sides to make sure the
> passwords matched.
>
> So then, when LAN A wants to connect to LAN B, the LAN A VPN server
> would look up LAN B's password in LAN A's /etc/shadow file, put together
> a key based on that hash, and then use that key to encrypt traffic going
> across. Similarly for LAN B. Since both sides have both accounts, nobody
> needs to send passwords across the Internet.
>
> If we had this in place, then Linux could do everything that Microsoft
PPTP
> does, but Linux wouldn't make the same implementation mistakes
> Microsoft made.
>
> How tough would this be to do? Does the idea make sense?
>
> - Greg Scott
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
prev parent reply other threads:[~2002-01-26 1:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-25 12:23 [LARTC] Proposal for reasonably secure GRE tunneling Greg Scott
2002-01-26 0:16 ` Daniel Wittenberg
2002-01-26 1:53 ` Greg Scott [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-101200998913833@msgid-missing \
--to=gregscott@infrasupportetc.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.