ssh-tunnels versus VPN: is one more secure?
Rahul
insecure WiFi access points and websites that use insecure protocols (non-
https) makes public-browsing pretty insecure. I know that a VPN is touted
as a pretty safe solution. Unfortunately I don't have an organizational
VPN I can use. An account at a VPN-website seems ok but its somewhat
expensive and I am not sure of the bandwidth.
I do have an always-on secure server so one option for me is to set up a
VPN-server myself on it. OTOH, I can already use Firefox through a ssh-
tunnel as a proxy. Does a VPN offer any advantages above that?
Any reccomendations for a VPN-server to install on my CentOS box?
--
Rahul
Tauno Voipio
The SSH tunnel forwards TCP connections only. A VPN forwards IP packets
or network frames. A IP packet forwarding VPN can link IP subnets
(with all IP-based protocols), and a network frame forwarding (bridged)
VPN can link so the participants seem to be in the same Ethernet.
Encrypted similarly, there is no essential difference in security
between a VPN and SSH tunnel.
My favourite for VPN is OpenVPN.
--
Tauno Voipio
tauno voipio (at) iki fi
Vilmos Soti
> What's the difference between a VPN and a ssh-tunnel?
With vpn, your computer becomes part of another network. All traffic
between your computer and the target network is encrypted.
You have access to all computers on the target network directly from
your computer.
With ssh, you just connect to another host, but you don't become
part of the server's network.
An analogy. Consider there is a discussion but you are not present.
There is a phone. You call the room where the discussion takes part.
If the phone in the remote room is a speaker phone, then your voice
can be heard by everybody and everybody can talk to you directly.
This is the vpn since for all practical purposes, you are virtually
present.
If the phone is not speaker-phone capable, then you can talk only
to one person at a time who relays the messages. That's the ssh
analogy.
Vilmos
Felix Palmen
> The SSH tunnel forwards TCP connections only. A VPN forwards IP packets
> or network frames. A IP packet forwarding VPN can link IP subnets
> (with all IP-based protocols), and a network frame forwarding (bridged)
> VPN can link so the participants seem to be in the same Ethernet.
For the sake of completeness: SSH tunnels just provide ONE TCP
connection, but of course, you can use this connection for a PPP
session, thus creating your very own "VPN" through an ssh tunnel. You
probably don't want to do that because it involves more overhead (the
TCP session is just unnecessary for VPN, dedicated VPN solutions use
either UDP (like OpenVPN), a custom IP transport protocol, or a custom
layer between IP and the transport protocol, all of these are more
efficient. But it IS possible.
Regards,
Felix
--
Felix Palmen (Zirias) + [PGP] Felix Palmen <fe...@palmen-it.de>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
Grant Edwards
> For the sake of completeness: SSH tunnels just provide ONE TCP
> connection, but of course, you can use this connection for a PPP
> session, thus creating your very own "VPN" through an ssh tunnel. You
> probably don't want to do that because it involves more overhead (the
> TCP session is just unnecessary for VPN, dedicated VPN solutions use
> either UDP (like OpenVPN), a custom IP transport protocol, or a custom
> layer between IP and the transport protocol, all of these are more
> efficient. But it IS possible.
The TCP session _may_ be necessary for a dedicated VPN if it has to
pass through a firewall that doesn't allow UDP traffic.
--
Grant Edwards grant.b.edwards Yow! I was making donuts
at and now I'm on a bus!
gmail.com
J G Miller
>
> You have access to all computers on the target network directly from your
> computer.
As far as I am aware this is only the case if the router on the target
network allows the setup of a static route when using VPN in routed mode,
which is preferable to bridged mode because
QUOTE
Overall, routing is probably a better choice for most people, as it is more
efficient and easier to set up (as far as the OpenVPN configuration itself)
than bridging.
Routing also provides a greater ability to selectively control access rights
on a client-specific basis.
UNQUOTE
from the HOWTO setup openVPN at
<http://openvpn.net/index.php/open-source/documentation/howto.html>
which is the best place to start reading about openVPN.
Rahul
news:iaa3ek$7db$2...@news.eternal-september.org:
> UNQUOTE
>
> from the HOWTO setup openVPN at
>
> <http://openvpn.net/index.php/open-source/documentation/howto.html>
>
> which is the best place to start reading about openVPN.
>
Thanks for all the pointers. In my case I'm going to use it purely for
secure web browsing. So I guess some of the other advantages that a VPN has
over a ssh-tunnel are lost for me.
The advantage of a tunnel is that it is so easy to set up and requires
almost no overhead on the server side (e.g. setting up OpenVPN).
--
Rahul
J G Miller
> In my case I'm going to use it purely for secure web browsing.
From <http://computingplugs.COM/index.php/SSH_tunnel_for_secure_web_browsing
QUOTE
However, for the simple purpose of creating a secure browsing environment
OpenVPN is overkill.
UNQUOTE
David Brown
> On 2010-10-27, Felix Palmen<fe...@palmen-it.de> wrote:
>
>> For the sake of completeness: SSH tunnels just provide ONE TCP
>> connection, but of course, you can use this connection for a PPP
>> session, thus creating your very own "VPN" through an ssh tunnel. You
>> probably don't want to do that because it involves more overhead (the
>> TCP session is just unnecessary for VPN, dedicated VPN solutions use
>> either UDP (like OpenVPN), a custom IP transport protocol, or a custom
>> layer between IP and the transport protocol, all of these are more
>> efficient. But it IS possible.
>
> The TCP session _may_ be necessary for a dedicated VPN if it has to
> pass through a firewall that doesn't allow UDP traffic.
>
OpenVPN can use tcp rather than udp if you want. The default is to use
udp, since there is less overhead (OpenVPN handles the reliability
already, so it has nothing to gain from using tcp). It can also work on
different ports - for example, you can run it over tcp on port 443,
which even the most restrictive firewalls usually allow.
And for even more completeness, it /is/ possible to pass UDP over a ssh
tunnel, using something like vtun to tunnel the UDP over TCP, and then
pass that TCP connection through ssh. You can also use netcat to do
much the same thing, I believe.
David Brown
If you want to set up a VPN, use OpenVPN - it is by far the easiest VPN
I have used, works well over firewalls (both client and server can be
behind firewalls and NAT routers, as long as you have a few
port-forwards in place), and works with all operating systems.
In general, use a VPN when you want to connect a lot of connections to
another network, or if you want to connect to many different machines.
But if you only need a few connections, then tunneling over ssh is
quicker to set up, and is safer in many ways (since you have severely
limited the traffic that is passing between machines).
You can imagine a VPN connection as being like connecting the client
computer directly to a network port on the server computer, with all the
advantages and disadvantages that has. A ssh tunnel is more like
opening a port forward through a firewall.
If you are using ssh, a /very/ useful trick is to use the "~" shortcuts
to add port forwards after the ssh session is already started. Type
"~?" to get a list.
The encryption used by ssh and VPN's is similar, and will be entirely
secure unless you have irritated the security services of a large country.
However, if all you want to do is access public sites in a secure way,
you should first check if the sites have https access. Many do, even
though they don't advertise it as much (https is more expensive at the
server end, because it takes more processor power). Failing that, you
might find it easier using something like TOR since you don't then need
any server acting as a proxy. There is even a firefox extension
designed to make it simple at <https://www.eff.org/https-everywhere>.
I haven't tried it myself.
Felix Palmen
> And for even more completeness, it /is/ possible to pass UDP over a ssh
> tunnel, using something like vtun to tunnel the UDP over TCP, and then
> pass that TCP connection through ssh. You can also use netcat to do
> much the same thing, I believe.
Of course, just as well as PPP for tunneling any IP traffic. The
overhead problem is similar, because the transport for the tunnel (ssh)
is done per TCP.
Rahul
news:JvGdnR3dHfqqpFTR...@lyse.net:
> However, if all you want to do is access public sites in a secure way,
> you should first check if the sites have https access.
Of course. https is the best solution. The ssh tunnel etc. is for sites
that that don't do things right. There's a large number of popular sites
that are bad.
What really scared the hell out of me was this recent Firefox plugin that
makes hacking insecure sites, literally, childs-play. Check out firesheep
http://www.sfgate.com/cgi-bin/blogs/hottopics/detail?entry_id=75679
Apparantly, the interface provides click-and-hack ability for facebook,
twitter, amazon amongst others.
>Many do, even
> though they don't advertise it as much (https is more expensive at the
> server end, because it takes more processor power). Failing that, you
> might find it easier using something like TOR since you don't then need
> any server acting as a proxy. There is even a firefox extension
> designed to make it simple at <https://www.eff.org/https-everywhere>.
> I haven't tried it myself.
Tor is promising but its overkill for me. It's intent is bulletproof
anonymization so it also tries to prevent cookies and a lot of other
functionality. At least the Tor-enabled-Firefox I tried in the past did
that. Besides the bandwidth through Tor is iffy and at the mercy of who all
is hosting at the moment. Not sure if, say, watching a streaming movie via
netflix would be a good idea.
--
Rahul
John Hasler
> Apparently, the [Firesheep] interface provides click-and-hack ability
> for facebook, twitter, amazon amongst others.
It isn't that bad. Basically, it only works if you are both using the
same WiFi and not using SSL. Since no prudent person would do anything
important over such an insecure connection...
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Rahul
news:87iq0m2...@thumper.dhh.gt.org:
>> Apparently, the [Firesheep] interface provides click-and-hack ability
>> for facebook, twitter, amazon amongst others.
>
> It isn't that bad. Basically, it only works if you are both using the
> same WiFi and not using SSL. Since no prudent person would do anything
> important over such an insecure connection...
I don't know about "prudent persons" but just walk into a coffee shop and
the number of people using facebook, twitter, amazon etc. seems a lot. Now,
it is arguable how "important" facebook is as a site. BUt still, it would
cause people a lot of misery.
One question I have is: Is the association clear: i.e. http -> insercure,
https-> secure? Or are there ways in which even a site where the links show
up as http could still be "secure" and vice versa?
Again, I'm not talking about the NSA trying to evesdrop here; just the
average joe sitting in the coffee shop with Firesheep.
--
Rahul
Rahul
> However, if all you want to do is access public sites in a secure way,
> you should first check if the sites have https access. Many do, even
> though they don't advertise it as much (https is more expensive at the
> server end, because it takes more processor power). Failing that, you
>
Turning this question the other way around: How difficult is it to enable
https on a standard website. Say, I host a wiki currently accessed over
http://foo.bar.edu/wiki/. If I wanted to allow people to access it over
https rather than http is that a straightforward thing? As in, is it like a
"black box" that I can convert the whole bunch of sites that we host from
http to https in one fell sweep. Or does it need modifying every page on a
case by case basis.
By googling I see that one has to buy a certificate but they don't seem too
expensive. Besides I see stuff like OpenCert which seems free. What's the
technology overhead?
--
Rahul
Grant Edwards
> David Brown <da...@westcontrol.removethisbit.com> wrote in
> Turning this question the other way around: How difficult is it to enable
> https on a standard website.
It's not all that difficult, but it can be damned expensive. HTTPS
involves a lot of CPU overhead compared to plain HTTPS. Setting up a
SSL/TLS connection involves some heavyweight public-key
number-crunching. The block-encryption used after that isn't quite so
bad, but it still burns a lot of CPUs.
Unless you're sitting on a lot of spare server capcity, you're going
to have to cough up a pretty big chunk of money for more servers or
crypto-offloading hardware.
> Say, I host a wiki currently accessed over http://foo.bar.edu/wiki/.
> If I wanted to allow people to access it over https rather than http
> is that a straightforward thing?
Yes, if you've got the money.
> As in, is it like a "black box" that I can convert the whole bunch of
> sites that we host from http to https in one fell sweep. Or does it
> need modifying every page on a case by case basis.
>
> By googling I see that one has to buy a certificate but they don't
> seem too expensive. Besides I see stuff like OpenCert which seems
> free. What's the technology overhead?
Crypto is expensive.
--
Grant Edwards grant.b.edwards Yow! I am a jelly donut.
at I am a jelly donut.
gmail.com
Ken Sims
On Thu, 28 Oct 2010 18:06:40 +0000 (UTC), Rahul
<nos...@nospam.invalid> wrote:
>Turning this question the other way around: How difficult is it to enable
>https on a standard website. Say, I host a wiki currently accessed over
>http://foo.bar.edu/wiki/. If I wanted to allow people to access it over
>https rather than http is that a straightforward thing? As in, is it like a
>"black box" that I can convert the whole bunch of sites that we host from
>http to https in one fell sweep. Or does it need modifying every page on a
>case by case basis.
In addition to other concerns ...
Unless something has changed, unlike HTTP where you can run many hosts
on one IP address, you can only run one HTTPS host per IP address
(because the host name is encrypted so it's not available until after
it's too late).
Disclaimer: It's been a while since I did any research on this, so
it's possible that the situation has changed since then.
--
Ken
Dave U. Random
R> Turning this question the other way around: How difficult is it to
R> enable https on a standard website. Say, I host a wiki currently
R> accessed over http://foo.bar.edu/wiki/. If I wanted to allow people
R> to access it over https rather than http is that a straightforward
R> thing? As in, is it like a "black box" that I can convert the
R> whole bunch of sites that we host from http to https in one fell
R> sweep. Or does it need modifying every page on a case by case basis.
R>
R> By googling I see that one has to buy a certificate but they don't
R> seem too expensive.
Once you have your certifate(s), use stunnel to wrap any
application that listens/connects to a port with no encryption.
That way you can have a secure session (and perhaps securely
authenticate yourself to the server).
David Brown
> John Hasler<jha...@newsguy.com> wrote in
> news:87iq0m2...@thumper.dhh.gt.org:
>
>>> Apparently, the [Firesheep] interface provides click-and-hack ability
>>> for facebook, twitter, amazon amongst others.
>>
>> It isn't that bad. Basically, it only works if you are both using the
>> same WiFi and not using SSL. Since no prudent person would do anything
>> important over such an insecure connection...
>
> I don't know about "prudent persons" but just walk into a coffee shop and
> the number of people using facebook, twitter, amazon etc. seems a lot. Now,
> it is arguable how "important" facebook is as a site. BUt still, it would
> cause people a lot of misery.
>
> One question I have is: Is the association clear: i.e. http -> insercure,
> https-> secure? Or are there ways in which even a site where the links show
> up as http could still be "secure" and vice versa?
>
"http insecure, https secure" is good enough as a first approximation.
There are plenty of ways to transmit data securely over an unencrypted
http connection - an obvious example would be to use a javascript
function to encrypt the data. But since it is easier for the website to
simply use https, that's what they normally do.
Breaking https is possible with man-in-the-middle attacks, but that
requires the attacker to be able to get in the middle. Other than that,
monitoring an https connection is practically speaking impossible. You
are also still vulnerable to phishing, dns poisoning, trojans, keystroke
loggers, etc, of course.
David Brown
> On 2010-10-28, Rahul<nos...@nospam.invalid> wrote:
>> David Brown<da...@westcontrol.removethisbit.com> wrote in
>
>> Turning this question the other way around: How difficult is it to enable
>> https on a standard website.
>
> It's not all that difficult, but it can be damned expensive. HTTPS
> involves a lot of CPU overhead compared to plain HTTPS. Setting up a
> SSL/TLS connection involves some heavyweight public-key
> number-crunching. The block-encryption used after that isn't quite so
> bad, but it still burns a lot of CPUs.
>
> Unless you're sitting on a lot of spare server capcity, you're going
> to have to cough up a pretty big chunk of money for more servers or
> crypto-offloading hardware.
>
Whether this is an issue or not depends on the sort of traffic you
expect. If you are talking about a site like facebook, then SSL is a
big cost. But for foo.bar.edu/wiki, using https will barely register on
the cpu loading.
But cpu costs are certainly one of the main reason that sites like
facebook don't use SSL (the other main reason is that they apparently
haven't the faintest clue about security, and certainly have a total
disregard for users' security and privacy).
>> Say, I host a wiki currently accessed over http://foo.bar.edu/wiki/.
>> If I wanted to allow people to access it over https rather than http
>> is that a straightforward thing?
>
> Yes, if you've got the money.
>
>> As in, is it like a "black box" that I can convert the whole bunch of
>> sites that we host from http to https in one fell sweep. Or does it
>> need modifying every page on a case by case basis.
>>
>> By googling I see that one has to buy a certificate but they don't
>> seem too expensive. Besides I see stuff like OpenCert which seems
>> free. What's the technology overhead?
>
You can buy a certificate fairly cheaply, or do your own self-signing.
Self-signed certificates give warning boxes on browsers because the
browser can't verify the authenticity of the certificate - but (assuming
the user accepts it despite the warning) you get exactly the same
encryption and protection.
> Crypto is expensive.
>
Crypto is a cost, but it is not necessarily expensive. If you are
running your own webserver for a small site, it is free - you already
have more cpu power than you need.
David Brown
No, you are basically correct. With http, the domain name in the http
header can be used for multi-hosting on the same ip address. But with
https, the header is encrypted - it is only once it gets to the https
server that it can be decrypted, and then you are already at the server.
The way around this is to have a https server front-end (either a web
server, or a web cache server) that handles the SSL encryption and
decryption, and passes the decrypted request back to another server for
handling.
Still, it is not as scalable as normal http serving (or at least, not as
easily scalable).
Another way to handle it is to have multiple https hosts use the same IP
address but different ports, but that can look a bit odd at the user end.
Ken Sims
On Fri, 29 Oct 2010 10:42:58 +0200, David Brown
<da...@westcontrol.removethisbit.com> wrote:
>The way around this is to have a https server front-end (either a web
>server, or a web cache server) that handles the SSL encryption and
>decryption, and passes the decrypted request back to another server for
>handling.
If you do this, because the front-end server doesn't know which host
is being requested at the point when the SSL connection is being
established, aren't there going to be certificate validation problems?
--
Ken
Grant Edwards
> On 28/10/2010 21:16, Grant Edwards wrote:
>> On 2010-10-28, Rahul<nos...@nospam.invalid> wrote:
>>> David Brown<da...@westcontrol.removethisbit.com> wrote in
>>
>>> Turning this question the other way around: How difficult is it to enable
>>> https on a standard website.
>>
>> It's not all that difficult, but it can be damned expensive. HTTPS
>> involves a lot of CPU overhead compared to plain HTTPS. Setting up a
>> SSL/TLS connection involves some heavyweight public-key
>> number-crunching. The block-encryption used after that isn't quite so
>> bad, but it still burns a lot of CPUs.
>>
>> Unless you're sitting on a lot of spare server capcity, you're going
>> to have to cough up a pretty big chunk of money for more servers or
>> crypto-offloading hardware.
>
> Whether this is an issue or not depends on the sort of traffic you
> expect. If you are talking about a site like facebook, then SSL is a
> big cost. But for foo.bar.edu/wiki, using https will barely register on
> the cpu loading.
Yep. That's what I meant by "sitting on a lot of spare server
capacity". Sites like foo.bar.edu/wiki probably have a lot of spare
server capacity they can use for crypto.
> But cpu costs are certainly one of the main reason that sites like
> facebook don't use SSL (the other main reason is that they apparently
> haven't the faintest clue about security, and certainly have a total
> disregard for users' security and privacy).
"Disregard" might even be a bit kind. I'd have proably said something
more like "contempt"
> Crypto is a cost, but it is not necessarily expensive. If you are
> running your own webserver for a small site, it is free - you already
> have more cpu power than you need.
Agreed.
--
Grant Edwards grant.b.edwards Yow! Now I understand the
at meaning of "THE MOD SQUAD"!
gmail.com
David Brown
There are certainly complications involved, and I have never tried it
myself. But I'm /reasonably/ certain there are ways around the single
IP limitation while still maintaining the certificate validity. I just
can't give you the details!
mvh.,
David
Rahul
@reader1.panix.com:
> Yep. That's what I meant by "sitting on a lot of spare server
> capacity". Sites like foo.bar.edu/wiki probably have a lot of spare
> server capacity they can use for crypto.
>
>
True about the cpu-capacity. I have a 8 core Xeon server. Load average is
rarely above 0.5.
--
Rahul
Rahul
> Breaking https is possible with man-in-the-middle attacks, but that
> requires the attacker to be able to get in the middle. Other than that,
> monitoring an https connection is practically speaking impossible. You
> are also still vulnerable to phishing, dns poisoning, trojans, keystroke
> loggers, etc, of course.
Most of the other vulnerabilities, though, can be attempted to be defeated
by a client side secure system. (keyloggers etc.) Phishing by an alert
user. But if someone on a coffee-shop wifi decided to havc into my http
facebook account normally one is helpless.
Not sure how exactly the "firesheep" attack vector works. I suspect through
ARP-poisoning though. Maybe installing something like arpwatch is another
security tool. At least one knows imidiately if multiple people areclaiming
the same MAC?
Of course, the ultimate would be never to use coffee-shop wifi but I doubt
that I have the self-discipline for that!
--
Rahul
Ken Sims
On Fri, 29 Oct 2010 16:41:39 +0200, David Brown
<da...@westcontrol.removethisbit.com> wrote:
>On 29/10/2010 16:06, Ken Sims wrote:
>> Hi David -
>>
>> On Fri, 29 Oct 2010 10:42:58 +0200, David Brown
>> <da...@westcontrol.removethisbit.com> wrote:
>>
>>> The way around this is to have a https server front-end (either a web
>>> server, or a web cache server) that handles the SSL encryption and
>>> decryption, and passes the decrypted request back to another server for
>>> handling.
>>
>> If you do this, because the front-end server doesn't know which host
>> is being requested at the point when the SSL connection is being
>> established, aren't there going to be certificate validation problems?
>>
>
>There are certainly complications involved, and I have never tried it
>myself. But I'm /reasonably/ certain there are ways around the single
>IP limitation while still maintaining the certificate validity. I just
>can't give you the details!
I thought about this more after my prior posting. I think you can get
a certificate that covers all hosts within a domain, so one
certificate would work for example.com, www.example.com,
shop.example.com, etc.
But I'm pretty sure that there's no way for a certificate to be valid
for more than one domain. (But I've never actual done SSL so I could
be talking out of my nether regions.)
If that's true, then one could use the front-end server method to
handle multiple https hosts _for_one_domain_ on one IP address with it
being transparent to the users.
But to have multiple https hosts across more than one domain on one IP
address would require the users to either accept an "invalid"
certificate or use non-standard ports. Non-standard ports could be an
issue for users behind a tightly controlled firewall.
--
Ken
David Brown
> David Brown<da...@westcontrol.removethisbit.com> wrote in
> news:BM6dnYCthIL5GFfR...@lyse.net:
>
>> Breaking https is possible with man-in-the-middle attacks, but that
>> requires the attacker to be able to get in the middle. Other than that,
>> monitoring an https connection is practically speaking impossible. You
>> are also still vulnerable to phishing, dns poisoning, trojans, keystroke
>> loggers, etc, of course.
>
> Most of the other vulnerabilities, though, can be attempted to be defeated
> by a client side secure system. (keyloggers etc.) Phishing by an alert
> user. But if someone on a coffee-shop wifi decided to havc into my http
> facebook account normally one is helpless.
>
Mostly agreed.
However, remember that anything you put on facebook should be considered
public domain knowledge anyway - facebook is not exactly renowned for
their watertight security or their consideration of user privacy. Your
facebook account was neither safe, private, nor protected from hackers
in the past, and it won't be even if you use https. Firesheep just
makes it easier for teenagers to crack it, that's all.
> Not sure how exactly the "firesheep" attack vector works. I suspect through
> ARP-poisoning though. Maybe installing something like arpwatch is another
> security tool. At least one knows imidiately if multiple people areclaiming
> the same MAC?
>
I don't know how firesheep works. I think it is unlikely to be using
ARP poisoning - remember, it works as a Firefox plugin. User-mode
programs in Windows, and non-root programs in Linux, are unable to send
the packets needed for arp poisoning AFAIK. And I don't think a Firefox
plugin would be able to put a network interface into promiscuous mode.
David Brown
That seems fair enough. I've only considered the case of multiple
subdomains of a single domain.
> But to have multiple https hosts across more than one domain on one IP
> address would require the users to either accept an "invalid"
> certificate or use non-standard ports. Non-standard ports could be an
> issue for users behind a tightly controlled firewall.
>
I think you are probably right here - it certainly makes sense as far as
I can see.
Richard Kettlewell
There is no need to speculate, the source is generally available. It's
a packet sniffer.
David Brown
I did a little checking (the source is available, but there are easier
ways to read about how it works) - it seems that on Windows it needs
wincap (which gives low-level access to the network interface, including
generation of odd packets and using promiscuous mode), and that it
doesn't currently work on Linux (no doubt because it can't do so without
root permissions).
So it is not limited as I thought.
David Brown
I've just been reading a bit of the FireSheep blog
<http://codebutler.com>, and came across this:
> Lack of IP addresses for SSL hosts. In the past, an SSL service
> required a dedicated IP address. This isn’t true any more with the
> advent of Server Name Indication (RFC 3546) and improvements in TLS.
I haven't looked into what this actually is, but I suppose it is a way
to have multiple domain names serving https from the same IP.
Ken Sims
On Tue, 02 Nov 2010 12:42:36 +0100, David Brown
<da...@westcontrol.removethisbit.com> wrote:
>I've just been reading a bit of the FireSheep blog
><http://codebutler.com>, and came across this:
>
>> Lack of IP addresses for SSL hosts. In the past, an SSL service
>> required a dedicated IP address. This isn’t true any more with the
>> advent of Server Name Indication (RFC 3546) and improvements in TLS.
>
>I haven't looked into what this actually is, but I suppose it is a way
>to have multiple domain names serving https from the same IP.
Thanks for pointing this out. I downloaded a copy of RFC 3546 and
looked for key parts. One of those parts is:
::3.1. Server Name Indication
::
:: [TLS] does not provide a mechanism for a client to tell a server
:: the name of the server it is contacting. It may be desirable for
:: clients to provide this information to facilitate secure connections
:: to servers that host multiple 'virtual' servers at a single underlying
:: network address.
::
:: In order to provide the server name, clients MAY include an extension
:: of type "server_name" in the (extended) client hello.
Long run, this does away with the one host (or at least one domain)
per IP address restriction.
Short run, it's going to take a while. Both the client and the server
have to support TLS and the TLS Extensions at least to the point of
providing the server_name (client) and accepting and using the
server_name for the virtual host (server).
Until most users are using browsers which can handle the client side,
servers will need to handle https requests without the server_name as
well as those with it (at least servers whose target audience is the
general public).
--
Ken
Lawrence D'Oliveiro
> On 2010-10-27, Felix Palmen <fe...@palmen-it.de> wrote:
>
>> ... (the TCP session is just unnecessary for VPN, dedicated VPN solutions
>> use either UDP (like OpenVPN), a custom IP transport protocol, or a
>> custom layer between IP and the transport protocol, all of these are more
>> efficient. But it IS possible.
>
> The TCP session _may_ be necessary for a dedicated VPN if it has to
> pass through a firewall that doesn't allow UDP traffic.
You don’t really want to run TCP over TCP.
Lawrence D'Oliveiro
> Breaking https is possible with man-in-the-middle attacks, but that
> requires the attacker to be able to get in the middle. Other than that,
> monitoring an https connection is practically speaking impossible. You
> are also still vulnerable to phishing, dns poisoning, trojans, keystroke
> loggers, etc, of course.
SSL/TLS is resistant to man-in-the-middle attacks. What it is not resistant
to is compromised certificate registrars.
Lawrence D'Oliveiro
> ... and that it doesn't currently work on Linux (no doubt because it can't
> do so without root permissions).
Linux allows for more fine-grained control of privileges rather than just
granting blanket root permissions. Looking at the capabilities(7) man page,
I think either CAP_NET_ADMIN or CAP_NET_RAW would be the appropriate
privilege for this to work.
David Brown
It is certainly possible to do that sort of thing. It is also possible
to use some sort of intermediary program running as root (perhaps using
the setuid bit) - I know that's more old-fashioned, and less secure,
than modern capabilities. I'm just guessing that this is the reason it
doesn't work on Linux as yet (especially since the developer clearly did
his initial investigations with Linux).
David Brown
Thanks for correcting me.
Grant Edwards
I didn't say that it was something you wanted to do, I said it was
something you sometimes have to do. If TCP is the only way to get
through a firewall, TCP over TCP sure beats running TCP over carrier
pidgeon.
--
Grant Edwards grant.b.edwards Yow! I wonder if I could
at ever get started in the
gmail.com credit world?
Lawrence D'Oliveiro
> On 03/11/2010 09:11, Lawrence D'Oliveiro wrote:
>
>> In message<H7WdnQIpzNCEZVLR...@lyse.net>, David Brown wrote:
>>
>>> ... and that it doesn't currently work on Linux (no doubt because it
>>> can't do so without root permissions).
>>
>> Linux allows for more fine-grained control of privileges rather than just
>> granting blanket root permissions. Looking at the capabilities(7) man
>> page, I think either CAP_NET_ADMIN or CAP_NET_RAW would be the
>> appropriate privilege for this to work.
>
> It is certainly possible to do that sort of thing. It is also possible
> to use some sort of intermediary program running as root (perhaps using
> the setuid bit) - I know that's more old-fashioned, and less secure,
> than modern capabilities.
PolicyKit?
Rahul
> However, remember that anything you put on facebook should be
> considered public domain knowledge anyway
Public domain, true. But you probably don't want other people masqurading
as you. Just a pain.
OTOH, the firesheep plugin works against a range of more "useful" sites
too. e.g. amazon.com
>- facebook is not exactly
> renowned for their watertight security or their consideration of user
> privacy. Your facebook account was neither safe, private, nor
> protected from hackers in the past, and it won't be even if you use
> https. Firesheep just makes it easier for teenagers to crack it,
> that's all.
True.
> I don't know how firesheep works. I think it is unlikely to be using
> ARP poisoning - remember, it works as a Firefox plugin. User-mode
> programs in Windows, and non-root programs in Linux, are unable to
> send the packets needed for arp poisoning AFAIK. And I don't think a
> Firefox plugin would be able to put a network interface into
> promiscuous mode.
From the other posts, I now realize that it doesn't use ARP poisoning.
But even if it wanted root access, that shouldn't be a problem. After all,
if I am the hacker, I'd have root on _my_ machine.
--
Rahul
Rahul
> I did a little checking (the source is available, but there are easier
> ways to read about how it works) - it seems that on Windows it needs
> wincap (which gives low-level access to the network interface, including
> generation of odd packets and using promiscuous mode), and that it
> doesn't currently work on Linux (no doubt because it can't do so without
> root permissions).
>
So, you could still use firesheep if you ran Firefox as root in Linux?
--
Rahul
Aragorn
identifying as Rahul wrote...
Nobody should *ever* run a webbrowser as root. It is very bad practice
to advise to people that they should do that.
--
*Aragorn*
(registered GNU/Linux user #223157)
Rahul
@news.eternal-september.org:
>> So, you could still use firesheep if you ran Firefox as root in Linux?
>
> Nobody should *ever* run a webbrowser as root. It is very bad practice
> to advise to people that they should do that.
>
>
Absolutely. Agreed. But we are talking about a _hacker_ here. He could very
well use firesheep+firefox as root from his machine. Assume "hacker
machine" has nothing important on it.
--
Rahul
Jon Solberg
(. But all the MS Windowsen boxes does that. It _can't_ be wrong. )
--
Jon Solberg (remove "nospam." from email address)
Richard Kettlewell
> David Brown <da...@westcontrol.removethisbit.com> wrote in
>> I did a little checking (the source is available, but there are
>> easier ways to read about how it works) - it seems that on Windows it
>> needs wincap (which gives low-level access to the network interface,
>> including generation of odd packets and using promiscuous mode), and
>> that it doesn't currently work on Linux (no doubt because it can't do
>> so without root permissions).
>
> So, you could still use firesheep if you ran Firefox as root in Linux?
AFAICS it should only be necessary to run the backend as root. It might
need as little as chmod 4755.
Lawrence D'Oliveiro
wrote:
> But we are talking about a _hacker_ here. He could very well use
> firesheep+firefox as root from his machine.
And he could very easily get pwned via some other bug as he’s trying to pwn
others.
Richard Kettlewell
> Rahul wrote:
>> But we are talking about a _hacker_ here. He could very well use
>> firesheep+firefox as root from his machine.
>
> And he could very easily get pwned via some other bug as he’s trying
> to pwn others.
They might anyway, whatever UID they run Firefox under. If they care,
presumably they use a scratch machine.
Rahul
>> a packet sniffer.
>>
>
> I did a little checking (the source is available, but there are easier
> ways to read about how it works) - it seems that on Windows it needs
> wincap (which gives low-level access to the network interface, including
> generation of odd packets and using promiscuous mode), and that it
> doesn't currently work on Linux (no doubt because it can't do so without
> root permissions).
>
> So it is not limited as I thought.
The blacksheep firefox extension is nice. Seems like a good way to protect
against firesheep:
http://techcrunch.com/2010/11/08/firesheep-blacksheep/
--
Rahul