|
|
·
|
·
|
·
|
·
|
·
|
·
|
|
SSH version 2 is a standard protocol in the Internet
world. It is an open protocol that many people have
analysed exhaustively for vulnerabilities and has been in
use for years. More information can be found on the IETF
web pages: http://www.ietf.org/ids.by.wg/secsh.html
|
|
Very little. Only a small extra field is added denoting
what tunnel the data belongs to. For normal sized
packets this is negligible, and even for very small data
packets, the normal TCP and IP headers are much larger.
In addition, compression can make the final data packets
being sent much smaller than without using the AppGate
system.
|
|
Traffic can be compressed before encrypted and
transmitted. Depending of the type of data, the total
traffic load may decrease with up to 50% (for example for
plain text such as web traffic). If network bandwidth is an
issue, for example for home users or users using mobile
devices, they will experience a performance boost. For
users being charged for amount of data being transmitted,
compression can decrease transmission costs as
well.
|
|
The protocol demands mutual authentication of the
server and the user (this is, for example, optional in SSL),
it supports tunnelling (also missing in SSL), it is an application
level protocol (as is SSL but not IPSec) and as
such it is independent of operating system versions and
service packs. It also runs on most systems and is able to
handle NAT, network address translation.
|
|
Yes, but please note that UDP is often used to allow
users to browse and see resources on a network, which,
from a security point of view, is not always a very good
idea. The AppGate NetBIOS proxy eliminates the need
for UDP for Windows file sharing while simultaneously
increasing security. This should minimise the need to use
UDP in most installations.
If UDP is still needed, AppGate supports UDP
through an optional IP Tunnelling Module which
supports not just UDP but also offers many other
features (please see the technical specifications for more
details).
|
There are some fundamentally different ways to
tunnel traffic using an AppGate client:
- Using standard tunnelling: all remote services are
seen by the applications as if they were executing on the
local machine, thus they can be accessed through the
server name “localhost”.
- The AppGate client can dynamically store the
names of accessible application servers in the hosts file
(i.e. it writes an entry for the server and gives it the IP
address 127.0.0.1), thus applications can access servers
using their real names, not only through the name
“localhost”. When the server is no longer available, the
entry is removed. This mechanism is completely dynamic
and invisible to the applications, thus they can refer to
remote machines using their correct server names.
- The AppGate clients can also use unique IP
addresses for remote hosts. Each host is given an
address like 127.0.0.x where “x” is a unique number for
each service or host the user has access to. This avoids
port conflicts if many application servers want to use the
same port number. This feature is by default enabled in
clients as of version 6.0 and can manually be enabled in
older clients.
- The AppGate client can make use of the IP
Tunnelling module. When installed, it intercepts all traffic
and is completely transparent. Note that all authentication,
encryption, etc., is still performed by the AppGate
client and that this module only adds another traffic interception
mechanism to the system.
|
|
Yes, this is handled automatically by the SSH
protocol. When the client and server negotiate session
crypto-keys (using the Diffie-Hellman scheme), the client
also verifies the AppGate server’s identity. This procedure
is done in such a way that it is impossible for someone to
act as a man-in-the-middle.
|
|