[pptp-server] Encryption with MS VPN

[tmk]

> However, I am not comfortable recompiling my kernel or compiling kernel
> modules, specifically the module that accompanies the pppd patch.
Actually,
> my main concern is supportability since I'd like to be able to upgrade
using
> the distribution and not have things break.  While I may be able to set
things
> up once, I am willing to admit that I don't have a firm enough grasp to
want
> to be responsible for re-fixing things after an upgrade.

you dont need to recompile the kernel, just the modules. As far as upgrading
in the future, it shouldnt be too much trouble, but for now, this is the
only way to get M$ compatible encryption

> My concern is with levels of encrytion.  I assume that the initial
negotiation
> for the GRE channel (is that the correct term?) takes place over a TCP
> connection.  Is that connection encrypted (is that what MS Win98 refers to
> when it talks about requiring an encrypted password?)?

mppe uses the password hash sent over the tcp channel (which is encrypted..
how well it is scrambled is another matter) to seed the encryption
algorithm. There is a (somewhat outdated) article on the pptpd site about
the quality of mppe encryption

see http://www.moretonbay.com/vpn/pptp.html

> Once the channel is set up and pppd is envoked to provide the IP
connection
> that the GRE protocol is carrying, I assume the encrypted connection at
the
> ppp level is identical an encryted ppp connection running over a modem.
Yes?
> Does the GRE encapsulation provide any (if even poor) encryption around
the
> ppp connection?

gre just ferrys packets back and forth, no additional encryption.. if you
want to encrypt ip traffic, look into ipsec.

> How open is a VPN connection from a Win98 machine when the "require data
> encryption" is not checked?  Forgive me for referring to these things in
terms
> of the Win98 VPN options :-)

the vpn link is just a standard ppp link without encryption, which is to say
mostly plaintext

> Is it simply security through obscurity because the protocol is GRE(47)
> instead of TCP(6)?

gre is a really basic proto (and any hacker looking to snarf data from pptp
tunnels will certainly read the rfc), and gre as it is used in pptp is
pretty much defined there, so your security, if any, has to come from
protocol level encryption (ipsec) or transport level (pppd). If you have
compression on, that could sort of be viewed as encryption, since data
wouldnt be plaintext, but that's shaky at best.

> Does anyone know whether the efforts here will be rolled into the pppd
source
> tree in the future and whether this will be rolled into distributions?  My
> impression is not anytime soon, but I'm hoping the recent changes to the
U.S.
> export regulations will change this.

it's unlikely that pppd will incorporate the mppe stuff, since they havent
put radius in yet, and that has been around for a while and is fairly
useful. Leaving things in kernel patch mode has worked well so far,

Kevin