SSH for Privacy and Anonymity

Security vs Privacy

Security vs Privacy

Security and Privacy of information are one of the key critical components for any individual, organization, and a nation. Privacy refers to the right or opportunity of individuals to determine when, how, and to what extent their personal information may be shared with others. Security of data or data protection, on the other hand, signifies the management of data and prevention controls existing to protect the privacy of information as per the privacy laws and acceptance by an individual. Organizations and nations involved in the collection and use of personal information have a duty to safeguard this information.

Being anonymous online for day to day operations is getting mainstream and there are multiple ways surfacing across technologies, which assist in achieving this state of privacy. Every day, it’s possible to go a step nearer towards being anonymous.

Even though most of the tools used with mere cryptographic mechanisms, such as encryption, primarily hides the content of the messages but not the end users communicating, there are cryptographic tools available, which provision mechanisms to hide your identity wherein network eavesdroppers may not even know where to find your communications, let alone snoop on them.

Relevance of Secure Shell (SSH)

Speaking of securing the data while it traverses over any network, SSH – Secure Shell or Secure Socket Shell is a cryptographic network protocol which provisions to create a secure channel over an unsecured environment.

Though it’s hardly the sole means of achieving online anonymity, the software such as Tor has turned out to be the most promised and developer friendly methods for using the Internet incognito. The free and open source program triple encrypts your traffic and bounces it through computers around the globe, making tracing it vastly more difficult.

Most Tor users know the program as a way to anonymously browse the Web. But it’s much more. In fact, Tor’s software runs in the background of your operating system and creates a proxy connection that links with the Tor network. A growing number of apps and even operating systems provide the option to route data over that connection, allowing you to obscure your identity for practically any kind of online service.

SSH primarily, on the other hand, uses public key cryptography for authenticating remote nodes, and could also authenticate a user.

The primary features of Secure Shell protocol are:

  • Providing strong encryption empowers privacy of your data
  • Provides integrity of communications, providing a guarantee that they haven’t been altered
  • Provides authentication viz. mechanisms to validate the proof of identity of senders and recipients
  • Provides authorization capabilities to access control to accounts and
  • Enables tunneling to encrypt TCP/IP based sessions

Key Features for SSH

  1. Privacy – typical protocols and networks don’t provide privacy i.e. anyone connected to the network wherein we have a multitude of hosts communicating through a common backbone may be able to sniff all the data traversing through the network.
Secure Shell - SSH

Secure Shell – SSH

Although, there are multiple ways of preventing the same (which is also coming in terms of smart networking devices), we do call it out as a serious issue. Passwords and sensitive data leakage are regularly targeted by such attack vectors.

Secure Shell provides end to end encryption, which is fundamentally based on public key cryptography. This is based on random keys which are securely negotiated for a particular session as well as destroyed when a session gets terminated. SSH supports multiple encryption algorithms, including but not restricted to 3DES (triple DES), IDEA, ARCFOUR, DES etc.

  1. IntegrityBasically, it assures the data transmitted from one end of a network has been unaltered till it reaches the other side. SSH enables integrity checking to detect any form of alteration due to multiple possibilities from network issues, packets getting lost or MITM (Man in the middle attack) etc.

Even though it is getting relatively easier to evade these attacks and thus can be fooled by a potential experienced attacker. Even though SSH encrypts the data stream so an attacker cannot modify the traffic to achieve a particular result, TCP/IPs integrity checking alone cannot prevent an attacker’s deliberate attempt of injecting garbage into the session.

One of the complex examples is the replay attack. It is also called as a playback attack wherein a valid data transmission is maliciously or through some mechanisms repeated towards the same destination. For example, let’s assume Bob the attacker is monitoring your session and also monitoring the keystrokes on your terminal.

In the course, you type a command rm –rf * within a small directory. Even though bob can’t read the encrypted SSH session data, but can correlate a burst of activities on your connection and capture the encrypted version of the command. Later, let’s assume you are working on your home directory and Bob now inserts the captured bits into your session. This will enable to erase all the files in your home directory.

The success rate of the attack will be pretty high since the packets Bob inserted are valid and even though the content could not be produced by Bob due to encrypted bits but potentially can replay the encrypted chunk later.

TCP/IPs integrity checks are performed on a per-packet basis, so it cannot detect Bob’s attack. The integrity check should have been applied to the whole data stream, ensuring that the bits arrive as they were sent in order and with no duplication.

The SSH 2 protocol verifies both the transmitted data hasn’t been altered and that it truly comes from the other end of the network connection.

  1. Authentication – it is the process to verify the identity of a resource and the user. Every SSH connection involves two way of authentication: the client verifies the identity of the SSH Server i.e. server authentication and the server verifies the identity of the user requesting access (user authentication). Server authentication ensures that the SSH server is genuine, guarding against an attacker redirecting your connection through a different node.

It also protects against MITM wherein an attacker sits undetectable between you and the server, relaying and altering the communication between the two parties who believe they are directly communicating with each other.

User authentication is conventionally done with password credentials, which unfortunately are a weak authentication scheme. To verify your identity you be required to reveal the password, exposing it to potential theft.

Authentication for SSH

Authentication for SSH

Furthermore, in order to recall a password, individuals are likely to keep it undersized and expressive, which makes the password easier for third parties to guess. For lengthier passwords, some individuals select verses or sentences in their native languages, and these passwords are close to being predicted and cracked.

SSH provisions authentication by password – encrypting the password as it traverses over the network. This can be considered as a vast improvement over other mostly used remote access protocols (such as Telnet, FTP) which largely send your password in the cleartext (i.e., unencrypted) over the network, where anybody through sufficient network access can steal it.

SSH offers added resilience and more manageable mechanisms: per user public key signatures, and an enhanced rlogin-style authentication, by way of host identity verified by the public key. Moreover, various SSH implementations support some other mechanisms and systems, including Kerberos, S/Key one-time passwords, RSA Security’s SecurID tokens, and the Pluggable Authentication Modules (PAM) system. An SSH client and server negotiate to decide which authentication mechanism to use, based on their corresponding configurations.

  1. Authorization – It is fundamentally deciding the actions which a user is privileged or not privileged to perform once authenticated. It occurs after authentication, as one cannot grant somebody privileges until you recognize who the user is. SSH servers have numerous ways of limiting the client’s actions. Authorization may be controlled at a server wide level (e.g., the /etc/sshd_config file for SSH1), or per account, depending on the authentication method used (e.g., each user’s files ~/.ssh/authorized_keys, ~/.ssh2/authorization, ~/.shosts, ~/.k5login, etc.).
  1. Forwarding – Forwarding or tunneling signifies encapsulating additional TCP-based service, such as Telnet or IMAP, within an SSH session. This conveys the security benefits of SSH (privacy, integrity, authentication, authorization) to other TCP-based services. For example, a regular Telnet connection conveys your username, password, and the rest of your login session in the clear text. By forwarding Telnet through SSH, all of this data is inevitably encrypted and integrity checked, and you may authenticate using SSH credentials.

SSH provisions authentication by password – encrypting the password as it traverses over the network. This can be considered as a vast improvement over other mostly used remote access protocols (such as Telnet, FTP) which largely send your password in the cleartext (i.e., unencrypted) over the network, where anybody through sufficient network access can steal it.

SSH offers added resilient and more manageable mechanisms: per user public key signatures, and an enhanced rlogin-style authentication, by way of host identity verified by the public key. Moreover, various SSH implementations support some other mechanisms and systems, including Kerberos, S/Key one-time passwords, RSA Security’s SecurID tokens, and the Pluggable Authentication Modules (PAM) system. An SSH client and server negotiate to decide which authentication mechanism to use, based on their corresponding configurations.

 

 

 

Leave a Reply