[스크랩]암호화, 전자서명, 인증서와 SSL

2018. 1. 2. 13:59

출처: https://okky.kr/article/405295

팁게시판에 좋은글이 있길래 퍼왔습니다

암호화의 필요성, 전자서명, 인증서와 SSL에 대해서 알아봅니다. 또한 무료 인증서(Let's Encrypt)를 발급 받는 과정을 안내합니다.

SSL (Secure Sockets Layer)

Packet Sniffing

TCP/IP(또는 TCP 위의 HTTP 같은 응용프로토콜) 패킷이 유선이나 무선 환경을 통해 전송되는 순간을 생각해봅시다. 발신자와 수신자 사이의 네트워크엔 수 많은 라우터나 다른 노드들이 존재하고 있습니다. 이때 이 사이에 위치한 해커는 손쉽게 인터넷을 흐르는 패킷들을 감청(Packet Sniffing) 할 수 있습니다. 즉, 여러분이 로그인을 하기 위해 전송한 아이디나 패스워드가 손쉽게 해커의 손에 들어갈 수 있다는 문제가 있습니다.

DNS Spoofing

또 해커는 피해자에 머신에 DNS Spoofing을 통해 자기 머신의 주소가 서버의 주소인 것처럼 속일 수 있습니다. 이땐 피해자와 서버 사이의 패킷을 중계하면서 정보를 가로채거나 변조 할 수 있습니다.

TCP - SSL/TLS - Application

이러한 문제는 웹 뿐 아니라, TCP/IP를 이용하는 모든 응용프로그램의 보안에 위협이 됩니다. 패킷을 해커가 읽거나 변조 할 수 없도록 암호화하기 위해서 네트워크의 TCP/IP - Application계층 사이에 SSL(Secure Sockets Layer)라는 계층을 고안하였습니다. (TLS; Transport Layer Security; 전송 계층 보안이라고 부르기도 함) 물론 이 때 TCP/IP 위에 SSL을 입히는 것은 응용프로토콜 개발자의 선택사항입니다.

SSL의 목적

패킷의 감청 방지
패킷의 변조 방지
서버의 신원 인증

암호화 (Encryption)

SSL의 구체적인 메커니즘을 살펴보기 전에, 암호화에 대해서 알아보겠습니다. 먼저 헷갈릴 수 있는 용어들과 비교해봅니다.

인코딩 (Encoding)

인코딩은 정보의 형태나 형식을 변환하는 처리를 말한다.

Base64는 바이너리 데이터를 6bit 포맷(26개의 문자로)의 문자열로 변환한다. (간단한 연산으로 복원 가능)

Base64("The quick brown fox jumps over the lazy dog") = "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw=="
Base64("The quick brown fox jumps over the lazy dog.") = "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4="
Base64("") = ""

해싱 (Hashing)

해싱은 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 처리를 말한다.

SHA-1 해시 함수는 최대 264비트의 메시지로부터 160비트의 해시값을 생성한다. (복원 불가)

SHA1("The quick brown fox jumps over the lazy dog") = "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12"
SHA1("The quick brown fox jumps over the lazy dog.") = "408d94384216f890ff7a0c3528e8bed1e0b01621"
SHA1("") = "da39a3ee5e6b4b0d3255bfef95601890afd80709"

암호화 (Encryption)

암호화는 임의의 키를 통해 평문을 암호화하여 암호문으로 만드는 처리를 말한다. 반대로 키를 통해 암호문을 평문으로 만드는 처리는 복화화라고 한다.

RSA 공개키 암호화 알고리즘은 큰 수를 소인수분해하기 어렵다는 점을 이용한 암호화 알고리즘으로 두개의 큰 소수를 기반으로 두개의 키를 생성하고, 이를 이용해 메세지를 암호화/복호화한다. (키가 있어야 복원 가능)

두 소수 p=163, q=167을 기반으로 생성한 암호키 e=847, d=127를 선택
평문 = hello
평문을 숫자로 표현 = 104 101 108 108 111
위 숫자를 e를 통해 암호화 = 16078 6642 1822 1822 13509
암호문을 d를 통해 복호화 = hello

이제 인코딩, 해싱, 암호화를 구분 할 수 있다면, 암호화의 두가지 방식에 대해서 알아보겠습니다.

대칭키 암호화

먼저 기원전부터 쓰인 대칭키 암호화 방식의 원리는 발신자와 수신자가 동일한 알고리즘과 그 열쇠를 공유하는 방식입니다. 쉽게는 알파벳을 1칸 앞으로(secret key) 옮기는 방식의 암호 알고리즘을 이용하면 hello는 ifmmp로 암호화 될 수 있으며, 마찬가지로 암호 키를 알고 있다면 역으로 복호화 할 수도 있습니다. 근대의 대칭키 암호화 역시 근본적으로 위와 같은 원리를 사용합니다.

대칭키 방식은 속도가 빠르고 연산량이 적지만, 키가 유실되면 보안 체계가 그대로 무너지기 때문에 키의 분배가 힘들다는 단점을 갖습니다.

비대칭키 암호화

대칭키의 키 분배 문제를 해결한 비대칭키 암호화 방식은 비대칭키와 달리 공개키(Public Key), 개인키(Private Key)라고 불리는 두개의 키를 생성합니다. 이 때 공개키로 암호화한 암호문은 개인키로만 복호화가 가능하며, 개인키로 암호화한 암호문은 공개키로만 복호화가 가능합니다.

이를 통해 발신자는 사전에 입수한 수신자의 공개키로 메세지를 암호화하고, 수신자는 전달 받은 암호문을 개인키로 복호화 할 수 있습니다.

비대칭키 방식은 서버-클라이언트와 같은 일대다 구조에서 키의 분배 문제를 해결할 수 있지만, 속도가 느리고 연산량이 많은 단점이 있습니다.

전자서명 (Digital Signature)

대표적인 비대칭키 알고리즘인 RSA는 대표적으로 전자서명에 많이 이용되고 있습니다. 전자서명은 말그대로 데이터의 작성자를 증빙하기 위해 데이터에 전자적인 서명을 첨부하는 것을 뜻합니다. 물론 전자서명은 수기서명과 동일한 효력을 지니고 있습니다.

Digital Signature with RSA

전자서명의 메커니즘은 비대칭키 암호화에 그 기반을 둡니다. 우선 원본 데이터를 공개된 방법으로 해싱하여 특정 길이의 문자열로 만듭니다. 그 해시값을 작성자의 개인키로 암호화한 전자서명을 생성하여 원본 데이터에 첨부하고, 수신자에게 발송합니다. 이후에 수신자는 받은 전자서명을 작성자의 공개키로 복호화하고 이를 받은 데이터를 해싱한 해시값과 비교합니다. 이때 두 해시값이 동일한지 비교하여 데이터의 작성자와, 데이터가 변조되지 않았음을 검증할 수 있습니다.

인증서 (Certificate)

자, 데이터를 안전하게 암호화하고 또 전자서명하여 교환하는데 성공했습니다. 하지만 한가지 더 문제가 남아있습니다. 단순히 전자서명만으로는 데이터 생성자, 즉 공개키 소유자의 실제(오프라인) 신원을 증빙할 수 없다는 문제입니다.

여기서 공개키/개인키 키 쌍의 소유자의 신원을 보증하기 위해서 인증서(Certificate)라는 개념이 등장합니다. 사용자들은 암호화나 전자서명에 이용할 키 쌍을 정부기관이나 은행 등 공인된 기관에서 개인정보를 인증하며 발급 받을 수 있습니다. 이 때 발급자는 기관으로부터 생성된 개인키와 그에 대한 인증서를 받게 됩니다. 이 때 그 인증서에는 일반적으로 아래와 같은 정보가 포함됩니다.

공인인증서

발급자의 신원 정보
발급자의 공개키
인증 유효기간
인증기관 정보
위 모든 내용에 대한 인증기관의 전자서명

즉, 인증서란 공개키와 그에 대한 인증기관의 보증으로 볼 수 있습니다. 다시말해서 본인의 인증서를 제공한다는 의미는, 본인의 공개키와 그 보증을 전달하는 것과 같습니다. 인증서와 그에 포함된 공개키를 통해 전자서명이나 암호화시에 데이터의 무결성을 검증 할 수 있습니다. (물론 인증서 발급 기관을 신뢰 할 수 있을 때)

물론 인증기관의 서명 대신에 자신의 전자서명을 첨부하여 (Self-Signed) Root 인증서를 만들 수도 있습니다.

인증기관 (CA; Certification Authority)

비대칭키 암호화의 속성을 이용하면, 데이터를 암호화하고, 데이터에 전자서명을 첨부하고, 인증서를 통해서 데이터 생성자의 신원을 보증 할 수 있습니다. 이처럼 공개키 및 인증서를 활용하는 소프트웨어, 플랫폼, 정책, 제도 등을 통틀어 공개키 기반 구조 (PKI; Public Key Infrastructure)라고 합니다. HTTPS, SFTP, SSH, SCP 등 SSL 위에서 작동하는 프로토콜, 또는 공인 인증서를 이용한 금융거래까지 모두 PKI에 속한다고 볼 수 있겠습니다.

X.509 구조

앞서 다룬바처럼 PKI에서 본인의 신원(공개키)을 인증서로 인증 할 필요가 있는 경우엔 공인된 인증서가 필요합니다. 이러다보니 PKI와 그 인증기관에 따라서 인증서의 포맷이 제각각일 수 있습니다. 이러한 상황에서 인증서의 범용성을 높히고, 웹(https) 같은 범국제적인 PKI를 위해서 X.509라는 인증서의 국제적인 표준 규격이 자리잡았습니다.

연쇄적인 인증 구조

X.509에서 인증서는 기본적으로 최상위 인증기관(CA; Certification Authority)의 루트 인증서를 시작으로 하위 인증기관들의 인증서를 타고 내려가 일반 사용자들의 인증서까지 연쇄적으로 상위 기관이 하위 기관을 인증하는 트리 구조를 띄고 있습니다. 따라서 사용자가 Root CA의 인증서(최상위 인증서는 자가서명되어 있음)를 신뢰 한다면, 그 하위의 모든 인증서를 신뢰 할 수 있는 구조가 됩니다.

한국의 공인인증서 및 개인키 역시 파일 양식 자체는 국제표준을 따르고 있지만, 그 파일들이 보관, 저장되는 위치와 방법이 독특하여 웹브라우저로는 사용이 불가능하다. 그 결과, 한국의 공인인증서를 이용하려면 이용자가 추가프로그램을 반드시 설치해야만 한다. 인증서는 원래 금융거래에만 사용되는 것이 아니라, 모든 전자적 거래(금전적이건 비금전적이건)에서 당사자의 신원을 확인하거나, 전자서명을 하는 용도로 사용될 수 있고, 한국의 공인인증서도 물론 그런 다양한 용도로 사용될 수 있다. 그러나 현실적으로 공인인증서는 전자금융거래에서 주로 사용되고 있다. 금융위원회는 전자금융거래에 "공인인증서 등"을 사용하도록 강제하고 있다가 의무사용 폐지됐다. ... (위키백과)

SSL HandShake

SSL의 목적

패킷의 감청 방지
패킷의 변조 방지
서버의 신원 인증

다시 본래의 주제 SSL로 돌아와서, SSL의 목적을 생각해보면, 이제 그 해답지가 보입니다. 비대칭키를 이용해 TCP 패킷들을 암호화(패킷의 감청 방지)하고, 패킷에 전자서명을 첨부하며(패킷의 변조 방지), 서버 측에서 공개키에 대한 인증서를 제공(서버의 신원 인증)한다면 모든 목적을 달성 할 수 있겠습니다.
(하지만 SSL이라고 완벽하진 않습니다. 중간자 공격 등, 지속적인 보안 취약점이 발생하고 있습니다.)

SSL Session Flow

SSL 연결 과정 (SSL HandShake)

서버는 클라이언트에게 인증서(+공개키)를 전달
이때 클라이언트는 서버의 인증서를 본인이 미리 알고있는 CA 목록을 통해 검증해서, 신뢰할 수 없는 서버의 경우에 유저에게 경고 할 수 있음
클라이언트는 대칭키 하나를 생성해 서버의 공개키로 암호화하여 서버에 전달
이후 양측간에 주고 받는 데이터는 대칭키로 암호화함

SSL에서는 비대칭키를 통해서 최초로 연결을 맺지만, 실제 통신에서는 서버측의 연산량을 절감하기 위해서 대칭키를 사용합니다. (비대칭키의 복호화 연산량은 대칭키 보다 약 1,000배 크다고 함)

HTTPS (HTTP over SSL)

HTTPS (Verified)

여기까지 인터넷 암호화 및 전자서명에 대한 기본적인 배경지식을 습득했습니다. 이제 본연의 웹으로 돌아가서, 웹서버에 SSL을 적용한 HTTPS를 구현해보도록 하겠습니다.

HTTPS (Not verified)

본인 스스로 서명한 인증서(Root Certificate)를 생성해서 HTTPS 웹서버를 구축 할 수도 있습니다. 하지만 위처럼 공인된 인증서가 아니기 때문에 클라이언트의 신뢰를 얻기 힘듭니다. 따라서 공인 인증서를 발급하게 되는데, 이때 일반적으로 인증서는 유료로 발급 받을 수 있습니다.

왜냐면 CA은 발급자에게 서비스를 제공해야하며, 인증서 발급자의 도메인 소유 정보를 확인해야하고, 발급자들의 인증 정보를 갱신하며, 웹브라우저들에게 본 기관의 Root Certificate를 내장하도록 부탁해야 하는 등, CA의 역할을 맡는데 여러 비용이 수반되기 때문입니다. 대표적인 국제 공인 CA 중에는 Comodo, Symantec (Verisign), GoDaddy 등이 있습니다.

국내에서는 한국인터넷진흥원(KISA)을 Root CA로 두는 국가 공개키 기반 구조 (NPKI; National Public Key Infrastructure)라고 불리는 PKI가 자리잡고 있습니다. 하지만 KISA에서 아직까지 국제 Root CA 검증 감사를 받지 않아서, 국내 CA에서 발급 받은 인증서는 특정 웹 브라우저들에게 신뢰받지 못 할 수도 있습니다.

Let's Encrypt

그러던 와중 2016년도에 Mozilla, Sisco, Akamai 등의 기업들이 Let's Encrypt라는 비영리 CA를 설립하고, HTTPS의 보급을 위해서 무료로 인증서를 발급해주고 있습니다.https://letsencrypt.org 에서 기부 및 안내를 볼 수 있고, https://certbot.eff.org 에서 인증서를 발급 받는 방법을 설명 받을 수 있습니다.

위의 certbot 웹사이트로 접속하면 운영중인 웹서버 종류 및 서버 OS를 선택 할 수 있습니다. 이후에 certbot 이라는 인증서 발급 및 갱신 프로그램을 설치하고, 실제로 발급 받는 방법에 대한 안내를 받을 수 있습니다. 여기서는 AWS 리눅스 환경에서 Node.js(Express) 웹서버에 SSL을 적용하는 과정을 적어보겠습니다.

1. certbot 설치 및 인증서 발급

# ssh로 도메인이 연결된 서버에 접속합니다.
dehypnosis-mac:keys dehypnosis$ ssh ec2-user@benzen.io

# wget은 주어진 URL에서 파일을 다운로드하는 프로그램입니다.
[ec2-user@benzen ~]$ wget https://dl.eff.org/certbot-auto

# 실행 권한을 주고
[ec2-user@benzen ~]$ chmod a+x certbot-auto

# 관리자 권한으로 실행하면, 이메일 주소 입력, 약관 동의, 이메일 공개(옵션)의 과정을 거칩니다.
# 이후에 certbot 프로그램이 자동으로 도메인 소유권을 인증하고, 인증서 및 개인키를 생성합니다.
# 서버 머신에 이미 Apache나 다른 웹서버가 설치되어 있따면, [1]이나 [3]의 옵션을 사용 할 수 있습니다.
# 그 외의 경우에는 단순히 [2]를 선택하면 certbot이 임시로 80 또는 443 포트에 웹서버를 가동하여 도메인 소유권을 확인합니다.
[ec2-user@benzen ~]$ ./certbot-auto certonly
FATAL: Amazon Linux support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!
Alternatively, you can install OS dependencies yourself and run this script
again with --no-bootstrap.
[ec2-user@benzen ~]$ sudo ./certbot-auto certonly
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Apache Web Server plugin - Beta (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
-------------------------------------------------------------------------------
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):kim@benzen.io

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: a

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: y
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel):workshop.benzen.io
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for workshop.benzen.io
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/workshop.benzen.io/fullchain.pem. Your cert
   will expire on 2017-08-27. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot-auto again. To
   non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

2. 인증서 및 개인키 확인

# 인증서 및 개인키(실제 파일의 바로가기 파일; 또는 symbolic link)는 다음 경로에 생성되어 있습니다.
[ec2-user@benzen ~]$ sudo ls /etc/letsencrypt/live/workshop.benzen.io
README  cert.pem  chain.pem  fullchain.pem  privkey.pem

# privkey.pem: 개인키를 Base64로 인코딩한 텍스트 파일입니다.
# fullchain.pem: 서버의 인증서와 상위 기관의 인증서를 Base64로 인코딩한 텍스트 파일입니다.
# cert.pem, chain.pem: cert.pem + chain.pem = fullchain.pem (일반적으로 fullchain.pem이 필요)

[ec2-user@benzen ~]$ sudo cat /etc/letsencrypt/live/workshop.benzen.io/README
This directory contains your keys and certificates.

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

Let's Encrypt, certbot을 떠나서, 인증서 발급 과정에서 기억 할 점은, CA가 도메인 소유권을 인증하고, 인증서 및 개인키를 생성해준다는 점입니다.
CA에 따라서 인증서 발급 과정이 웹 UI상에서 이루어질 수도 있고, Let's Encrypt처럼 셸 프로그램을 제공 할 수도 있습니다.

3. 서버에 HTTPS 적용

// Express.js의 경우엔 아래처럼 443 포트에 https 서버를 실행시킬 수 있습니다.
// http의 기본 포트가 80인 것처럼, https의 기본 포트는 443입니다.
const path = require('path');
const fs = require('fs');
const https = require('https');
const app = express();

// ... 서버 로직

const sserver = https.createServer({
  key: fs.readFileSync('./ssl/privkey.pem'),
  cert: fs.readFileSync('./ssl/fullchain.pem'),
}, app).listen(443);
console.log('Secure server running at port 443');

// 같은 로직의 http 서버를 동시에 운영 할 수 도 있습니다.
const server = https.createServer(app).listen(80);
console.log('Non-Secure server running at port 80');

Apache, Nginx, Tomcat, IIS 등, 기타 상용 서버를 사용하는 경우에는 플랫폼에서 제공하는 방법에 따라서 개인키와 인증서를 연결하고 특정 포트에 https 서버를 실행 할 수 있습니다. 주의사항은 Let's Encrypt의 인증서의 유효기간은 90일이기 때문에, 만료일이 다가올 때마다 certbot을 이용해서(ex; sudo ./certbot-auto renew) 갱신하거나, Cron 등의 운영체제 서비스에 스크립트를 등록하여 이 과정을 자동화 할 필요가 있습니다.

(심화) SSH vs SSL/TLS에 대해서

이전에 공부했던 SSH 또한 SSL/TLS처럼 핸드쉐이킹에 비대칭키를, 패킷 통신에는 대칭키를 이용합니다. 또한 응용 프로세스를 위해서 TCP 패킷을 암호화하는 것도 동일합니다.

그렇다면 두 암호화 프로토콜이 어떻게 다르게 쓰이는 지 고민해볼 수 있겠습니다. 이 부분은 심화적인 내용이므로 사전에 설명하지 않은 용어들이 나올 수 있습니다. 네트워크, 암호화 및 SSH 프로토콜에 관심이 있는 분들이 읽어 보시길 바랍니다.

SSH는 일반적으로 엔드유저를 위한 ssh 클라이언트 프로그램을 의미하지만, 응용 프로토콜 하위의 하나의 암호화 프로토콜로도 볼 수 있겠습니다.

SSL/TLS는 인증서 포맷으로 X.509을, SSH는 독자적 포맷(ssh-keygen 프로그램을 통해서 생성)을 쓴다는 점을 제외하면, 모든 SSL과 SSH 응용은 대체가 가능합니다. FTPS(FTP over SSL)와 SFTP(Secure FTP), HTTPS와 SHTTP는 모두 비대칭키와 대칭키 암호화를 이용하므로 보안에 있어서 원리적인 차이가 없습니다.

둘은 비슷한 역할을 수행하지만, 그 응용 방식에서는 큰 차이가 납니다. SSH는 서버에서 sshd를 22포트에 열고 ssh 클라이언트와 암호화된 패킷을 주고 받으면서 포트 포워딩; 프로세스 간에 패킷을 중계하는 방식으로 응용됩니다. 실제로 sftp, scp, ssh 클라이언트의 트래픽은 모두 sshd의 22포트로 들어갑니다.

SSH 터널링을 통해 패킷을 암호화하고 방화벽을 우회

이처럼 SSH를 응용하는 프로그램은 항상 SSH 터널링(터널은 ssh 클라이언트로 쉽게 생성 할 수 있음)을 응용합니다. 또한 이러한 특성으로 SSH는 방화벽 우회 및 프록시 구축, 또는 외부에서 기존 프로그램의 패킷을 암호화하는 등에 많이 쓰이고 있습니다.

이처럼 SSH는 여러 서버 호스트와의 연결 및 응용에 쓰이는 프로토콜 내지는 활용도가 높은 프로그램입니다. 이렇게 ssh 클라이언트가 다용도로 쓰이기 때문에, ssh 클라이언트는 핸드쉐이크 과정에서 (기본적으로) 로컬의 공개키를 무더기로 보냅니다.

반면에 SSL/TLS는 포트포워딩 방식보다는 각 응용 프로토콜마다 개별 포트를 바인딩하고, 서버 프로세스 자체에서 인증서를 갖고 핸드쉐이킹 과정을 처리하고 패킷을 주고 받습니다. 따라서 SSL/TLS를 응용하기 위해서는 프로그램에서 내부적으로 프로토콜 수준부터 구현해야 하겠습니다.

위 내용을 정리하자면 SSH나 SSL/TLS는 모두 암호화를 위한 프로토콜로 볼 수 있고, SSH는 SSL/TLS에 비해 더 이식성있게 응용 할 수 있다는 생각입니다.

'IT > Etc' 카테고리의 다른 글

시도해볼만한 프로그래밍언어 8종 (0)	2018.01.24
네트워크 관리사 족보/네트워크 관리사 2급 (0)	2018.01.12
구글 검색유입 추가시키기 (1)	2018.01.08
SVN Ignore 사용하기 (2)	2018.01.08
애드센스 적용해보기 (0)	2018.01.02

물고기 개발자의 블로그