HTTPS

HTTP over Secure Socket Layer
Web上でよく使われるHTTPは以下の理由で脆弱である

HTTPメッセージは暗号化されておらず、直接通信して盗聴しやすい.

通信相手が確認されないため、偽装の可能性がある.

容易変調

盗聴の可能性

HTTPメッセージは、要求と応答の内容がそのままの形で通信され、盗聴可能なTCP/IPネットワークが使用されているため、ユーザがログインのためにパスワードを入力すると、要求されたHTTPメッセージにおいて盗聴可能な形で通信される.

偽装の可能性

HTTPを使用して通信している場合、このメッセージがどこから来たのか、信頼できるクライアントまたはサーバから来たのかは判断できません.http://www.royce.com表示アドレスに信頼されていないクライアントが含まれている場合、そのアドレスに接続されているサーバでは区別できません.

ちょうせい

HTTPを使用した通信は、通信中に変更または変更することができます.
これらのセキュリティ・ホールを解決してHTTPを使用するためにHTTPSが出現した.

HTTPS

Secure Socket Layer
HTTPSは、HTTPからTCPへの通信とは異なり、SSL(TLS)というセキュリティ層を介してTCPと通信する.この場合、SSLを使用して暗号化、証明書、安定性保護などの機能を提供し、使用することができます.

SSL (TLS)

SSLは開発後に標準化機構IETFの管理に発展しTLSに改称した.
TLS 1.0はSSL 3.0を継承している.
しかし、TLSよりSSLという名前が多く使われています.
SSLの動作手順を理解する前に、対称鍵と公開鍵を理解する必要がある.

たいしょうキー

暗号化する任意のデータまたはドキュメントについて、暗号化鍵は復号鍵と同じ方法で対称鍵(共通鍵)と呼ばれます.
次の例を示します.

#텍스트 내용이 "Hello, Royce"인 `beforeEnc.txt`파일을 생성하고,
echo 'Hello, Royce' > beforeEnc.txt;

#-des3방식으로 beforeEnc.txt파일을 암호화 한 뒤 afterEnc.bin으로 생성
openssl enc -e -des3 -salt -in beforeEnc.txt -out afterEnc.bin;

この場合、暗号化を実行する手順で鍵を設定する必要があります.

#확인
cat afterEnc.bin
#Salted__OOy /��t��
#                 �P)���~�%

暗号化がうまく行われていることがわかります.
暗号化されたafterEnc.binを復号する場合は、暗号化フェーズで同じ鍵を入力して復号できます.

#afterEnc.bin 복호화
openssl enc -d -des3 -in afterEnc.bin -out afterDec.txt;

cat afterDec.txt
#Hello, Royce

この暗号化鍵は復号鍵と同じ方法で対称鍵と呼ばれています
ただし、ここでの問題は、復号化されたオブジェクトに鍵がない場合、その鍵を送信する必要があるが、その鍵は暗号化されていないことである.HTTPで通信すると、暗号化要求後に要求を受けたサーバに対応する鍵がなく、同時に鍵を送信して復号すると、復号鍵が露出する可能性がある.
これらの問題を解決するために,公開鍵方式が現れた.

公開鍵

公開鍵方式は、暗号化対象に1つの鍵しかない対称鍵とは異なり、2つの鍵がある.公開鍵と非公開鍵(秘密鍵)を有し、公開鍵は他の誰にでも提供することができる.
公開鍵で暗号化し,公開鍵で復号する.鍵を転送する必要がないので、この方法は安全です.秘密鍵を露出しない限り.

公開鍵/秘密鍵の作成

#private.pem이라는 비공개키를 생성(1024bit)
openssl genrsa -out private.pem 1024;

#비공개키에 대한 공개키 생성
openssl rsa -in private.pem -out public.pem -outform PEM -pubout;

公開鍵による暗号化

echo 'Hello, Royce' > beforePem.txt

#beforePem.txt를 생성한 공개키로 암호화
openssl rsautl -encrypt -inkey public.pem -pubin -in beforePem.txt -out afterEnc.ssl;

cat afterEnc.ssl;
#ɖo�~�g�>��f�Y�V?]ؤ�G��mZ�
#                         `�M-:ա�YY�]��4ӵ~�{�����+M�޼����9)�O���AQǃ�pvl��9�ٿ�|h��8�YO`�U0��g_h+9T�Qe&%

復号by秘密鍵

#비공개키로 복호화
openssl rsautl -decrypt -inkey private.pem -in afterEnc.ssl -out decrypted.txt

cat decrypted.txt
#Hello, Royce

非対称鍵を使用すると、通信をより安全に暗号化できるように見えるが、対称鍵よりも遅く、計算負荷が高いという欠点がある.
対称キーと非対称キーを混ぜて使うのが適当だという.
もう1つの欠点はCAの出現であり,暗号化された公開鍵が本当かどうかを証明することは困難である.秘密鍵ではなく公開鍵を使用して暗号化し、秘密鍵を持つサーバにいつでも復号要求を送信することもできます.
ということでCA登場

CA

Certificate Authority
前述の公開鍵の問題を解決するには、次の役割が必要です.

クライアントが接続するサーバが信頼できるサーバであることを確認する

.

SSL通信のための公開鍵

を提供する必要がある.
厳格な審査を受けた認証機関(CA)が担当する.

認証機関の使用手順

まずサーバ公開鍵をサーバが使用するCAに提出する.

CAは、サーバの公開鍵を暗号化し、証明書とともにサーバに送信する.

これで、暗号化(by CAの秘密鍵)サーバ公開鍵を含む証明書が要求されたクライアントに送信されます.

証明書を受け取ったクライアントは、インストールされたCAの公開鍵を使用してサーバの公開鍵を復号します.
通信による受信のリスクが高いため、ブラウザ(クライアント)は通常、主なCAの公開鍵を予め内蔵しておく.

このとき,復号に成功すると,認証機関が発行した証明書と実際のサーバの公開鍵であることがわかり,信頼できる(CA)クライアントである.

SSL HandShakeとは?

HTTPSで通信するために、클라이언트 - 서버は、以下の악수(HandShake)のプロセスを経るであろう.

クライアントはClient Hello 메세지(랜덤 메세지)をサーバに送信し、SSL通信を開始する.

サーバがSSL通信可能であれば、Server Hello 메세지(랜덤 메세지)に応答してサーバに通信可能であることを通知し、サーバは証明書をクライアントに送信する.

クライアントは、ブラウザに組み込まれたCAの公開鍵を使用して、サーバから取得した証明書を検証(復号)します.

サーバは、サーバHello Doneメッセージを送信し、最初のSSL通信が終了したことを通知します.

クライアントは、サーバに送信されたClient Hello(랜덤 메세지)と、サーバから応答されたSever Hello(랜덤 메세지)とを組み合わせてPre-Master-Secret-Keyを作成する.
(Pre-Master-Secret-Keyは、クライアントとサーバの間で使用される共通鍵です.)

クライアントは、証明書内のサーバの公開鍵を使用してPre-Master Secret Keyを暗号化し、サーバに送信する.

サーバは、自身の秘密鍵を使用して暗号化されたPre-Master-Secret-Keyを復号する.

クライアントとサーバはPre-Master-Secret-Keyであり、공통키と呼ばれるため、以降の通信は대칭키(공통키)方式で通信することができる.