1.2. SSL은 뭐고, 인증서는 뭔가?
Secure Socket Layer(SSL) 프로토콜은 넷스케이프사에서 웹서버와 브라우저 간의 보안 통신을 위해 만들어졌다. SSL은 통신할 때 인증기관(Certificate Authority, CA)라는 것을 이용해서 서로 인식하게끔 되어 있다. 이 과정을 간단하게 설명하면 다음과 같다.
[웹브라우저] 보안 페이지를 요청한다. (일반적으로 주소에 https:// 라고 붙는다).
[웹서버] 자신의 공개키를 인증서와 함께 웹브라우저로 보낸다.
[웹브라우저] 웹서버의 인증서가 신뢰할 수 있는 제3자(신뢰할 수 있는 루트 인증기관,Trusted root CA)에게 서명되었는지 확인한다. 그리고 인증서가 아직 유효한지, 그리고 접속하려는 사이트와 연관되어 있는지 최종 확인한다.
[웹브라우저] 최종 확인이 되었으면 웹브라우저는 대칭 암호화키(대칭키)를 생성해서 웹서버의 공개키로 암호화한 후 송신한다. URL이나 기타 HTTP 데이터는 방금 생성한 대칭키를 이용해서 암호화한 후 웹서버로 전송한다.
[웹서버] 자신의 개인키를 이용해서 수신한 대칭키의 암호를 풀고, 이것을 이용해서 나머지 URL이나 기타 HTTP 데이터의 암호를 푼다.
[웹서버] 처리 결과(HTML문서+HTTP데이터)를 대칭키를 이용해서 암호화한 후 웹브라우저로 전송한다.
[웹브라우저] 대칭키를 이용해서 HTTP데이터와 HTML문서의 암호를 풀고 화면에 출력한다.
위 개념은 SSL의 기본 동작 원리이므로 반드시 이해하고 넘어가야 한다. 다음 장에서 각 용어에 대해 자세히 설명할 것이다.
1.2.1. Private Key/Public Key:개인키/공개키
개인키/공개키 암호의 가장 큰 특징은 하나의 키로 암호화를 하면, 해당되는 쌍의 다른 키로만 풀 수 있는 점이다. 예를 들어 A키와 B키가 하나의 쌍이라면, A키로 암호화를 하면 B키로만 풀 수 있으며, B키로 암호화를 하면 A키로만 풀 수 있다. 이 특징이 이해하기 어려울 수도 있지만, 일단 그렇다고 암기하는 것이 좋다. 이러한 키는 소수(Prime numbers)를 기반으로 생성되며, 그 길이(bit단위)가 길수록 암호화의 강도가 쎄진다. 개인키/공개키는 이러한 이론을 바탕으로 약간 응용한 기법이다. 하나의 키는 비밀로 간직하고, 다른 키는 모두에게 공개한다. 그렇게하면 다른 사람들이 여러분에게 메시지를 보낼 때 공개키를 이용해서 암호화된 메시지를 보낼 수 있다. 이 메시지는 비밀키를 가지고 있는, 여러분 혼자만이 풀 수 있다. 그렇다면 반대의 경우엔 어떻게 될까? 메시지를 개인키로 암호화해서 보낸다면 어떻게 될까? 이 경우에는 모든 사람이 메시지를 열어볼 수 있을 것이다. 하지만 특정 개인키를 가지고 암호화했다는 것이 증명되기 때문에, 특정인이 보낸 메시지라는 것을 증명할 수 있다. 주의해야할 점은 메시지를 보낸 사람이 누구라는 것을 증명할 뿐이지, 메시지 자체는 모든 사람이 열어볼 수 있다는 것이다!
이제 서로 간에 공개키를 주고받기만 하면 된다. 그냥 상대방에게 공개키를 보내달라고만 하자. 어짜피 공개되어도 무방한 키이기 때문에 별다른 보안장치 필요없이 인증서와 함께 전송하면 된다.
평문—>[공개키]—>암호화된 메시지—>[개인키]—>평문
1.2.2. 인증서
자. 앞에서 개인키/공개키 기법을 익혔으니 그것을 적용하기만 하면 된다. 하지만 잘 생각해보면 뭔가 문제가 있다는 것을 깨달을 수 있을 것이다. 내가 받은 공개키가 그 사람(또는 웹사이트)의 것이라는 것을 어떻게 알 수 있을까? 혹시 제3자가 상대방을 가장해서 보낸 것이 아닐까? 이를 확인하기 위해 일일히 직접 상대방을 찾아가 볼 수도 없는 노릇이다. 이를 해결하기 위해서 모든 사람이 믿을 수 있는 제 3자가 나서게 된다. 그 사람의 인증서는 너무나도 유명해서 기본적으로 모든 사람이 알고 있다고 해보자. 그 사람은 특정 키가 그 사람의 것이라는 서명한 인증서를 발급한다. 여기에는 E-mail 주소, 소유자의 이름, 인증서 사용 용도, 유효기간, 위치, Common Name(CN, 웹사이트 주소나 E-mail 주소), 인증서ID 등등의 정보가 저장되어 있다. 그리고 마지막으로 이 정보를 공개키와 공개키의 해쉬값과 같이 저장해서 인증서를 만든다. 이러한 개념은 신뢰하고 있는 사람이 서명한 인증서 역시 신뢰할 수 있다는 생각을 전제로 한 것이다. 이런 신뢰 관계가 트리 형태로 형성되어 점점 불어난다. 웹브라우저의 경우를 살펴보자. 신뢰할 수 있는 제 3자의 인증서는 인증기관(Certification Authorities, CA), 또는 루트 인증기관(Root CA)이라고 불리며, 브라우저속에 기본적으로 내장되어 있다. 이러한 CA는 인증서나 인증 철회된 인증서 목록을 전문적으로 관리하는 기관이다. CA가 서명한 인증서는 조금이라도 변경되면 서명이 깨지기 때문에 안전하다. 인증서를 서명할 때 자신의 개인키로 서명할 수도 있다. 이러한 인증서는 자체 서명 인증서(Self signed certificate)라고 불린다. 모든 루트 인증기관의 인증서는 자체 서명되어 있다.
Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org Validity Not Before: Nov 20 05:47:44 2001 GMT Not After : Nov 20 05:47:44 2002 GMT Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a: 9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36: b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4: 7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86: 08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd: 94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25: da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e: 42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a: 6c:14:e2:ae:62:e7:6b:30:e9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F X509v3 Authority Key Identifier: keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org serial:00 Signature Algorithm: md5WithRSAEncryption 34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd: aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57: 2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96: 34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62: e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5: 0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06: ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af: bc:5a ——-BEGIN CERTIFICATE——- MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB 0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI 2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2 JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0 cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa——-END CERTIFICATE——-
위 내용은 인증서 샘플이다. 위에서 볼 수 있다시피 인증서는 서명자의 정보, 인증서 주인의 공개키, 인증서 유효기간, 인증서 서명값 등으로 이루어져 있다. 비밀키는 인증서에 들어가 있지 않으며, 절대로 들어가서도 안되고 노출되어서도 안된다. 이 인증서를 가지고 인증서 주인에게 암호화된 메시지를 보낼 수 있으며, 인증서 주인이 보낸 메시지가 진짜라는 것을 확인할 수 있다.
1.2.3. 대칭키
공개키 기반 암호화 알고리즘은 정말 강력한 알고리즘이다. 하지만 실전에서 써먹을려고 하면 좀 생각해봐야 한다. 공개키 기반 암호화 알고리즘은 비대칭 형태이기 때문에 복호화를 하기 위해서는 다른 키가 반드시 필요하다. 암호화한 키로는 암호화만 가능할 뿐, 풀 수가 없다. 반면에 대칭키 기반 알고리즘은 하나의 키로 암호화하고 해독한다. 보안 측면에서는 키가 노출될 가능성이 적은 공개키 기반 암호화 알고리즘이 안전하다. 하지만 공개키 기반 알고리즘의 문제점은 너무 느리다는 것이다. 그렇다면 안전하고 속도도 빠른 방법은 없을까?
해결책은 대칭키를 공개키로 암호화해서 전송하면 된다. 물론 개인키는 전송할 필요도 없고, 해서도 안된다. 이렇게 하면 대칭키는 송,수신자만 알아볼 수 있다. 여기에다 대칭키를 랜덤으로 생성하는 기능까지 넣으면 혹시 한번 누출되더라도 다음 통신할 때는 다른 키를 사용하기 때문에 안전하다. 이렇게 대칭키를 송신한 후에는 대칭키를 가지고 암호화해서 통신하면 된다.
keytools 사용법
특정 스토어의 인증서 목록 확인
D:\interpark\air\java\jdk1.8.0_161\jre\bin>keytool -list -keystore “D:\interpark\air\java\jdk1.8.0_161\jre\lib\security\cacerts”
특정 스토어에 특정 인증서 추가
D:\interpark\air\java\jdk1.8.0_161\jre\bin>keytool -import -file “D:\kidongyun\ca\jinair_com_HQSSL.pem” -keystore “D:\interpark\air\java\jdk1.8.0_161\jre\lib\security\cacerts” -storepass “changeit”
portecie 사용법
java 에는 기본적으로 루트 CA가 있따.
여기에다가 각 hostname 별로 인증서를 만들고 로컬일경우 이걸 바라보도록 수정한거임.