Apache Http 서버에서 443 포트(Https)를 인증서를 이용해서 서비스하는 경우가 있다.
이때 디버깅하는 방법은 openssl을 이용하는 방법이 있다.
이를 통해서 openssl의 handshaking 방법을 이해할 수 있으며, acl 이슈나 웹 서버의 설정 이슈들을 이를 통해서 확인이 가능하다. 정상적이지 않으며 아래와 같은 handshaking에서 문제가 발생할 것이다.
ssldump 나 wireshark, etheral 같은 프로그램으로도 충분히 볼 수 있다.
google.com:443 포트 즉, https://google.com:443 포트에 접속하는 연결을 하는 예제이다.
아주 전형적인 ssl 통신이다.
kimyonghwan@ubuntu:~$ openssl s_client -host google.com -port 443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN
gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L
05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5
u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6
z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1907 bytes and written 281 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: 11ABAB39B14A001469136E9C7B278415E005D44571B487BE2C04B51963F78160
Session-ID-ctx:
Master-Key: 21EBAA2443B524F04FDD88A53B84211C0C91F915DB06A05929BBB5F98F29F0F6D13D489A9A622B0C1C90A8A07858635F
Key-Arg : None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 1a b6 4a e9 9e fd 36 e2-74 0a 05 ba 4c bf b3 d3 ..J...6.t...L...
0010 - c4 57 97 e3 fe c4 56 34-ee 19 e1 82 04 56 59 fe .W....V4.....VY.
0020 - 21 35 c9 e9 f6 a7 d4 5f-6e d7 d5 64 85 57 c7 18 !5....._n..d.W..
0030 - 4a 2b 5d 2d db 09 71 96-0c 48 85 d7 5b 9f 37 ab J+]-..q..H..[.7.
0040 - 8a 15 27 9c 35 0c 38 e2-54 08 cd a9 4c ef c2 bb ..'.5.8.T...L...
0050 - cc a3 ad bf 10 03 58 3a-ba 89 d3 40 36 71 a7 d5 ......X:...@6q..
0060 - 20 1a 5f 79 3e 4a 77 b7-9b ab 70 3c e6 7c 06 9c ._y>Jw...p<.|..
0070 - 21 05 3a 5c be de 3e 63-67 6c fd fd 65 5b c7 6b !.:\..>cgl..e[.k
0080 - 12 7c ad da d0 6d 43 6d-68 29 78 20 f2 4e 59 48 .|...mCmh)x .NYH
0090 - 60 fb 31 1b `.1.
Start Time: 1319126774
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
get / http/1.1
HTTP/1.0 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 11782
Date: Thu, 20 Oct 2011 16:06:19 GMT
Server: GFE/2.0
<!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<title>Error 400 (Bad Request)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{background:url(https://t1.daumcdn.net/cfile/tistory/223EEF4B56E6EB481D"BORDER-BOTTOM: #dbe8fb 1px solid; BORDER-LEFT: #dbe8fb 1px solid; PADDING-BOTTOM: 10px; BACKGROUND-COLOR: #dbe8fb; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BORDER-TOP: #dbe8fb 1px solid; BORDER-RIGHT: #dbe8fb 1px solid; PADDING-TOP: 10px" class=txc-textbox>
참고로,
ssl version2는 보약 취약성이 발견되어서 사용하지 않는다.
kimyonghwan@ubuntu:~$ openssl s_client -host google.com -port 443 -state -ssl2
10184:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453:
SSL은 HTTP와 TCP 중간에 걸친 Layer이며, HTTPS 연결시 SSL 통신을 하게 된다.
smtps, nntps, ldaps, ftps, pops 등 다양한 secure channel에 공통적으로 사용될 수 있다.
자세한 내용은 워낙 많은 자료들이 인터넷에 많은 관계로 참조하면 된다.
- https://developer.connectopensource.org/display/CONNECTWIKI/SSL+Handshake
- http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
- http://pchero21.com/798
- http://www.openssl.org/
- http://www.ibm.com/developerworks/kr/library/l-openssl.html
- http://www.joinc.co.kr/modules/moniwiki/wiki.php/article/Openssl%C0%BB_%C0%CC%BF%EB%C7%D1_%C6%C4%C0%CF_%BE%CF%C8%A3%C8%AD
하고 싶은 얘기는 SSL Handshaking이다. 트러블 슈팅이 큰 도움이 된다.
약간 광범위한 얘기이긴 하지만. 무척이나 중요한 내용이다.
* http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-1 의 이미지 참조
이미 진행했던 구글 서버와의 openssl 통신 결과의 의미를 파악해 본다.
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
CONNECTED(00000003)
이 내용을 쉽게 풀어 써볼 수 있다.
1. Client(터미널에서 openssl 요청, 브라우져)가 Https를 이용해서 Server(google.com) URL로 통신을 시도한다. Hello 라는 통신인데, 지원 가능한 암호방식, 키 교환 방법, 압축 방식을 서로 의사소통한다.
2. Server(google.com)가 인증서를 client에 전달한다.
3. Client에서는 Server 인증서 public key 얻어옴 (기본적인 인증서에 대한 검증 절차를 거침. 인증서의 도메인과 실제 요청하는 도메인이 갖은지. CA가 정확하게 인증했는지 등등)
5. Client에서는 public key를 이용한 pre-master key(RSA 키교환) 를 생성하고 서버에 전달하여 상호간의 키를 교환하도록 한다. (key exchange)
6. Client에서 인증서 검증 정보를 보내고, SSL 통신에 의해 결정된 암호방식, 키교환 방법, 서명방식, 압축방식을 다음부터 적용할 것을 정한다. (cipher spec)
6. Server는 Client로부터 받은 pre-master key(또는 pre master secret)를 private key로 디코딩하고 Session ticket으로 생성하고 Client에 전송한다. (session ticket)
7. Server 에서는 Session Ticket를 이용하여 Server와 Client간의 발생하는 모든 통신은 암호화가 되게 한다.
보안쪽은 조금만 이해안되면 혼란스러운 부분이 있어서 좋은 레퍼런스를 참조한다.
통신과 키 생성원리
참조 : https://developer.connectopensource.org/download/attachments/34210577/Ssl_handshake_with_two_way_authentication_with_certificates.png
이해하기 좋은 그림이 있어서 소개한다.
참조 : http://www.kannel.org/download/kannel-wtls-snapshot/wtls.html
ssldump을 이용해서 application 단에서의 통신을 이해할 수 있다.
kimyonghwan@ubuntu:~$ sudo ssldump -a -A -H -i eth0
New TCP connection #1: ubuntu(53920) <-> hx-in-f105.1e100.net(443)
1 3.0262 (3.0262) S>C TCP FIN
1 3.0263 (0.0000) C>S TCP FIN
New TCP connection #2: ubuntu(59780) <-> hx-in-f106.1e100.net(443)
2 4.7585 (4.7585) S>C TCP FIN
2 4.7586 (0.0000) C>S TCP FIN
New TCP connection #3: ubuntu(53922) <-> hx-in-f105.1e100.net(443)
3 0.5294 (0.5294) S>C TCP FIN
3 0.5295 (0.0001) C>S TCP FIN
New TCP connection #4: ubuntu(59782) <-> hx-in-f106.1e100.net(443)
4 1 0.0519 (0.0519) C>SV3.1(90) Handshake
ClientHello
Version 3.1
random[32]=
4e a0 5b 72 1f f2 e5 9b fc cf 6f ab 3f 8c 03 5d
c6 b0 23 b0 71 11 87 4d d3 ad 67 57 32 9b c7 7d
cipher suites
Unknown value 0x39
Unknown value 0x38
Unknown value 0x35
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Unknown value 0x33
Unknown value 0x32
Unknown value 0x2f
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5
Unknown value 0xff
compression methods
unknown value
NULL
4 2 0.1044 (0.0524) S>CV3.1(53) Handshake
ServerHello
Version 3.1
random[32]=
4e a0 5b 72 79 8e 98 9b 19 71 29 5b 74 7e b8 e7
ec 94 96 39 75 f1 21 66 f5 1b f9 29 b6 94 c1 70
session_id[0]=
cipherSuite TLS_RSA_WITH_RC4_128_SHA
compressionMethod NULL
4 3 0.1044 (0.0000) S>CV3.1(1625) Handshake
Certificate
4 4 0.1044 (0.0000) S>CV3.1(4) Handshake
ServerHelloDone
4 5 0.1061 (0.0016) C>SV3.1(134) Handshake
ClientKeyExchange
EncryptedPreMasterSecret[128]=
bb bb 6a 34 58 49 a7 bd 98 12 17 d8 4a d0 8d f3
ff 47 01 23 c1 15 61 d2 7d 53 70 73 5a a1 3a cb
ae 70 51 37 cb 08 9b a4 61 14 77 b8 7b a7 3f 8e
b4 f9 36 af ea 95 ae 0d 9e d1 db 84 5d 09 88 39
25 06 77 ee dc e9 0a 3a 68 c0 c2 82 58 d4 b2 1b
77 11 ca 4b 96 26 bb 7a db 9e b1 42 f2 7c ff fc
72 ad 09 8d 72 ec 5e 0a fe a7 09 fe 2e ea 44 d8
2d 95 0e 9f 84 e1 22 9d 64 c7 70 f0 38 72 42 34
4 6 0.1061 (0.0000) C>SV3.1(1) ChangeCipherSpec
4 7 0.1061 (0.0000) C>SV3.1(36) Handshake
4 8 0.1556 (0.0495) S>CV3.1(158) Handshake
dss_fixed_dh4 9 0.1556 (0.0000) S>CV3.1(1) ChangeCipherSpec
4 10 0.1556 (0.0000) S>CV3.1(36) Handshake
4 11 9.3738 (9.2181) C>SV3.1(35) application_data
4 12 9.7738 (0.3999) C>SV3.1(21) application_data
4 13 9.8238 (0.0499) S>CV3.1(165) application_data
4 14 9.8238 (0.0000) S>CV3.1(1175) application_data
4 15 9.8239 (0.0000) S>CV3.1(1345) application_data
4 16 9.8754 (0.0515) S>CV3.1(1345) application_data
4 17 9.8755 (0.0000) S>CV3.1(311) application_data
4 18 9.8755 (0.0000) S>CV3.1(1345) application_data
4 19 9.9252 (0.0496) S>CV3.1(1345) application_data
4 20 9.9252 (0.0000) S>CV3.1(1345) application_data
4 21 9.9252 (0.0000) S>CV3.1(141) application_data
4 22 9.9252 (0.0000) S>CV3.1(1345) application_data
4 23 9.9253 (0.0000) S>CV3.1(1345) application_data
4 24 9.9253 (0.0000) S>CV3.1(960) application_data
4 9.9253 (0.0000) S>C TCP FIN
4 25 9.9261 (0.0008) C>SV3.1(22) Alert
4 9.9264 (0.0002) C>S TCP FIN
'c or linux' 카테고리의 다른 글
웹 서비스 HTTPS 연결시 소켓 끊김 현상 및 해결사례 (1) | 2011.10.21 |
---|---|
wireshark를 ubuntu에 사용하기 (0) | 2011.10.21 |
파일 버퍼 관련 커널 정보 수집 (0) | 2011.10.19 |
Apache 2.2.21 패치 (mod_proxy_ajp 패치와 apache killer 보완) (9월 13일) (0) | 2011.09.16 |
내가 사용하는 리눅스의 네트웍(네트워크) 카드가 zero copy를 지원하는지 확인 (1) | 2011.09.09 |