iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🔐

Understanding Keys, Signatures, and Encryption in TLS, SSH, and SAS

に公開
Azure
Security
SSH
TLS
Mermaid
tech

Introduction

TLS/HTTPS, SSH, and Azure Storage SAS all involve "keys," "signatures," and "encryption." However, even though the same terms are used, what they actually do differs significantly.

In this article, I will organize the following three using diagrams:

  • TLS/HTTPS: Website server certificates and encrypted communication
  • SSH: Server verification and user public key authentication
  • SAS: Time-limited access URLs for Azure Storage

To give the conclusion first:

Mechanism Main Purpose Usage of Signatures/Keys Actual Data Communication
TLS/HTTPS Verify that the server is authentic CA signs the certificate, PC/browser verifies with CA public key Encrypted with symmetric keys
SSH Server verification and user authentication User signs with private key, server verifies with public key Encrypted with symmetric keys
SAS Grant limited access to Storage HMAC signature using Account Key or User Delegation Key Protected by HTTPS

The key point is that public key cryptography is mainly used for identity verification, signature verification, and key exchange, while actual communication data is encrypted using symmetric keys.

Overview

TLS/HTTPS: Server Certificate Verification and Symmetric Key Communication

In HTTPS, the first step is to confirm, "Is this website authentic?"

The certificate contains the server's public key, domain name, expiration date, issuer, and the CA's signature. It does not contain the symmetric key itself.

To summarize:

CA private key
  -> Used to sign the server certificate

CA public key
  -> Used by PC/browser to verify the certificate

Server private key
  -> Used to prove the server's identity

Server public key
  -> Contained within the server certificate

Symmetric key
  -> Created during TLS handshake and used for actual data communication

In short, you can remember HTTPS like this:

HTTPS is a mechanism that uses CA trust to verify a server certificate, then performs high-speed communication using symmetric keys.

SSH: Server Verification and User Public Key Authentication

SSH performs two main types of verification:

  • Is the destination server authentic?
  • Is the connecting user legitimate?

1. Server Verification

When connecting via SSH for the first time, you may see a confirmation prompt like this:

The authenticity of host 'xxx' can't be established.
Are you sure you want to continue connecting?

This is a prompt asking, "Do you trust this server's host key?"
If you trust it, the server's public key information is saved in your local known_hosts file.

2. User Public Key Authentication

For user authentication, you place the user's public key on the server side.

Server side: ~/.ssh/authorized_keys
Client side: Private key like ~/.ssh/id_ed25519

What is important here is that you do not encrypt with the private key and send it; you sign with the private key. The private key itself is never transmitted.

3. Communication is Encrypted with Symmetric Keys

SSH does not encrypt communication content using public key cryptography throughout the entire session either.
Just like TLS, it creates a session symmetric key through key exchange, and subsequent communication is encrypted using that symmetric key.

SAS: Azure Storage Signed Access URLs

SAS for Azure Storage is not a public key signature system like TLS or SSH.
Essentially, it is an HMAC signature based on a shared key.

With Service SAS or Account SAS, you sign using the Storage Account Key.
With User Delegation SAS, you sign using a User Delegation Key obtained after authenticating with Microsoft Entra ID.

SAS primarily protects conditions such as:

  • Which resource can be accessed
  • Whether it is read-only or if writing is also allowed
  • How long it is valid
  • Whether it is restricted to HTTPS only
  • Whether it is restricted to a specific IP only

If you modify the contents of a SAS URL on your own—for instance, changing sp=r (read-only permission) to sp=rw—the string subject to signature changes, so it will not match the result of the recalculation on the Storage side. Therefore, access will be denied.

Is SSH Secure?

In conclusion, the SSH protocol itself is quite robust.
However, what is dangerous in practice is not SSH itself, but operations such as the following:

  • Allowing password login
  • No passphrase on the private key
  • Private key leaked from a PC or repository
  • Ignoring known_hosts warnings
  • Bastion server widely exposed to the Internet
  • Ability to move laterally to internal servers after logging into the bastion
  • Lack of audit logs
  • Remaining keys for retired employees or unnecessary users

In other words, while SSH is a "secure communication method," it is only secure if it is operated securely.

Image of a Bastion Configuration

A bastion server is an entrance to internal servers.
Therefore, if managed incorrectly, attacks will focus on the bastion.

A bad configuration looks like this:

SSH widely exposed to the Internet
  ↓
Password login allowed on the bastion
  ↓
Wide connectivity from the bastion to internal servers
  ↓
Private keys or credentials remain on the bastion

In this case, even if you are using SSH, it is quite dangerous.

Why are ports 22 and 3389 considered particularly dangerous?

The reason ports 22 and 3389 are said to be dangerous is not that the port numbers themselves are weak.
In many cases, these are administrative ports for direct login to the OS or servers.

SSH  = TCP 22
RDP  = TCP 3389
HTTPS = TCP 443

If SSH on port 22 or RDP on port 3389 is exposed to the Internet, it looks like this to an attacker:

This server has an administrative login entrance
  ↓
Login attempts might be possible
  ↓
Target brute force, leaked keys, vulnerable settings, old versions
  ↓
If successful, obtain OS operation privileges

Especially for RDP and SSH, the impact of a successful login is significant.
Instead of accessing a single feature of a web screen, there is a possibility of gaining access to the server's shell or desktop.

On the other hand, port 443 is not necessarily safe.
Since port 443 is a public entrance for Web and API, it is naturally scanned and attacked.
However, port 443 is often designed with the assumption of being public, making it easier to place defensive mechanisms in front of it.

Port Common Use Nature when attacked How to protect
22 SSH Easily targeted for direct OS login Do not expose, IP restriction, public key auth, Bastion, SSM, IAP
3389 RDP Easily targeted for direct Windows login Do not expose, VPN, Bastion, MFA, Just-In-Time access
443 HTTPS Target web/API vulnerabilities WAF, auth, MFA, rate limiting, audit, LB/API Gateway

The important point is not "it is not attacked because it is 443," but that "443 is easier to consolidate into WAF, authentication, MFA, auditing, and managed entrances."

In short, to summarize:

22/3389
  -> Administrative login entrance, so it easily becomes a target for scanning, brute force, and vulnerability exploitation

443
  -> Does not mean it is not attacked
  -> However, it is easier to consolidate into WAF, authentication, MFA, auditing, and managed entrances

Therefore, in practice, rather than exposing port 22 or 3389 directly on a VM, configurations that use Azure Bastion, AWS Systems Manager Session Manager, GCP Identity-Aware Proxy, or VPN to consolidate management access into more easily controllable entrances are preferred.

Practical Checklist for Using SSH Securely

If you are going to use SSH, you should at least cover these points.

Countermeasure Reason
Disable password login Avoid brute force attacks
Disable root login Prevent direct entry as a privileged user
Attach a passphrase to the private key Minimize damage if the key file leaks
Do not ignore known_hosts warnings Detect man-in-the-middle attacks or server replacements
Restrict connection source IP Reduce the SSH attack surface
Minimize bastion users Tighten entrance permissions
Keep audit logs Be able to track who did what and when
Do not use agent forwarding carelessly Reduce risk of key abuse via bastion
Delete unnecessary public keys regularly Do not leave access for retired/transferred employees

In cloud environments, consider managed connection methods like the following if possible:

  • Azure Bastion
  • Azure VM Just-in-Time access
  • AWS Systems Manager Session Manager
  • GCP Identity-Aware Proxy

These are options to facilitate connections based on identity and with audit logs, without opening SSH ports directly to the Internet.

How to Remember TLS, SSH, and SAS

Finally, if you want to remember it very roughly:

TLS/HTTPS
= Mechanism where CA guarantees server certificate
= Actual communication is symmetric key

SSH
= Server verification + User public key authentication
= Sign with private key, verify with public key
= Actual communication is symmetric key

SAS
= Time-limited access URL for Azure Storage
= HMAC signature, not public key signature
= The URL itself is secret information

In a diagram:

Summary

While TLS, SSH, and SAS all involve "keys" or "signatures," their purposes differ.

  • TLS/HTTPS verifies server certificates and establishes a secure communication path.
  • SSH verifies the destination server and connecting user to log in securely.
  • SAS issues temporary, limited access URLs for Azure Storage.

Also, while SSH is a secure mechanism, it is inherently dangerous if the exposure scope of the bastion server, key management, and log management are handled incorrectly.

In practice, it is important to design SSH not by seeing it as "secure so it is fine," but by including where to place the entrance, who is allowed to enter, and what to record.

Ports 22 and 3389 are considered particularly dangerous because they easily provide direct access to the OS as administrative login entrances. On the other hand, while port 443 is also attacked, it is easier to consolidate into WAF, authentication, MFA, auditing, and managed entrances, making it easier to defend as a design.

References

Discussion