1.
초 간단기록.HTTPS 에 대한 간단 설명 과SSL 하드웨어 가속기를 이용한 성능 향상<br />2011.6.22<br />

2.
문서 안에서의 용어 정리<br />Http 서버 80포트로 서비스되는 일반적인 웹 서버<br />Https 서버 (또는 보안 서버)<br />443포트로 Http 프로토콜에 SSL 보안 통신하는 웹 서버<br />

3.
HTTP/HTTPS<br />해커 공격 가능<br />내부 망<br />* HTTP (80)<br />User<br />Apache<br />Tomcat<br />Network<br />Switch<br />개인정보가 파라미터로 전달될 수 있음<br />ID:aa<br />PW : aa1234<br />주민번호 :111<br />해커 공격 불가능<br />* HTTPS (443)<br />HTTPS<br />HTTPS<br />User<br />Apache<br />Tomcat<br />Network<br />Switch<br />파라미터 정보를 암호화<br />Asdafklj!234325SDG<br />Certificate설치/설정mod_ssl이용<br />SSL을 이용 (openssl)<br />

4.
HTTPS 서버의 용도<br />Https 서버를 통해서 다음을 방지한다.<br />Sniffing 방지<br />Phishing 방지<br />데이터 변조<br />

5.
인증서<br />인증서는 보통 2년 단위로 관리 (1년짜리도 쓰기도 함)<br />개별 도메인당으로 관리된다. ssl.service.com<br />웹 브라우져는SSL 연결을 하고 서버 인증서를 받고 어떤 인증서인지 확인한다. 이때 신뢰하는 싸이트(인증기관, CA, Certificate Authority)라면 괜찮지만, 이상하다 싶으면, 주소표시줄 색깔을 달리해서 경고해준다.즉, 웹 브라우져는 인증기관 목록을 미리 가지고 있다. <br />인증서 내부에서는 Chain이 있다. 즉, 웹 브라우져에서 가지고 있는 내부의 CA 목록에는 없지만, 인증서를 만들 수 있는 조직이 여러 군데 두게 한다. Chain의 최상위에는 웹 브라우져에서 인증하는 CA의 sign된 정보를 바탕으로 SSL 통신을 Valid하게 처리한다.<br />

6.
HTTPS서버의 SSL 통신<br />리눅스, ssldump툴을 이용<br />New TCP connection #304: 1.1.1.1(1981) <-> a.service.com(443)<br />304 1 0.0123 (0.0123) C>S Handshake<br />304 2 0.0127 (0.0004) S>C Handshake<br />304 3 0.0127 (0.0000) S>C ChangeCipherSpec<br />304 4 0.0127 (0.0000) S>C Handshake<br />304 5 0.0202 (0.0074) C>S ChangeCipherSpec<br />304 6 0.0202 (0.0000) C>S Handshake<br />304 7 0.0260 (0.0058) C>S application_data<br />304 8 0.1921 (0.1661) S>C application_data<br />304 9 0.2001 (0.0079) S>C application_data<br />304 0.2001 (0.0000) S>C TCP FIN<br />304 0.2699 (0.0698) C>S TCP FIN<br />Wireshark, tcpdump도 많이 도움됨<br />

7.
SSL 통신을 자세하게 보는 방법 <br />openssls_client -connect <https서버도메인>:443 -state -debug<br />

8.
HTTPS는 언제 사용?<br />현행법상 개인정보를 취급하는 영리 목적의 사업자는 반드시 써야 하는 의무사항임<br />보안서버가 구축되지 않으면, 1천만원 이하의 과태료가 부가됨<br />고객 정보를 귀하게 여겨야 함<br />법률 근거<br />정보통신망 이용촉진 및 정보보호 등에 관한 법률 28조, 55조, 67조<br />정보통신망 이용촉진 및 정보보호 등에 관한 법률 시행 규칙 3조 2항<br />개인정보의 기술적,관리적 보호조치 기준 5조<br />

9.
운영 이슈<br />2년 마다 한번씩 공인 인증서 발급되어야 한다. <br />모든 서버에 Certificate 파일을 두어야 한다. <br />Expire Time에 맞게 잘 배포해야 한다. (스케쥴을 잘 걸어야 함. 잘못하면 서비스 운영 실패!!)<br />새로 서버를 설치할 때를 위해서인증서를 잘 관리해야 한다.<br />조직 이동시 인수인계를 잘 해야 함<br />=> 손이 많이 감.<br />

10.
운영이슈<br />이미지도 SSL??<br />Apache 쪽으로 요청하는 것들은 Rewrite Rule을 이용하여 http 서버로 이미지 Redirection되게<br />JSP쪽은 Tag library를 이용하여 이미지 Redirection되게 함. <br /><ul><li> 최대한 HTTPS 서버에 부담이 되지 않도록 함</li></li></ul><li>비용 이슈<br />운영 서버에 적용하려면 해당 서비스의 개발 서버에도 동일하게 인증서를 설치해야 함예를 들어, dev, alpha, beta, real 총 4개의 인증서를 설치해야 함<br /> 한 인증서당 70만원이면 총 280(4*70)만원 비용 지출. <br /><ul><li>만약 웹 서비스가 많다면 그에 맞게 총 비용은 늘어날 수 밖에 없다.

11.
개발 서버 (dev,alpha,beta)서버에서는 10년짜리 인증서를 설치하는 게 좋다. => 운영 서버의 인증서만 구입하면 된다.인증서는 최장 25년짜리 까지 만들 수 있음..</li></li></ul><li>성능 이슈<br />HTTPS (SSL)통신의 가장 문제는성능이다.<br /> => Data encryption/decryption +ssl handshake 비용<br />속도가 거의 나오지 않는다.(경험 #1) – 동일한 URLhttp : 44https : 8(경험 #2) – 동일한 URLhttp: 10000TPS 이상https : 200~210TPS 이상<br />트래픽몰렸을때, 빨리 풀리지 않음.<br />

12.
성능 이슈<br />https 서버<br />리퀘스트가한순간에 몰렸다가 풀리는 상황에서도, CPU는 좀처럼 떨어지지 않았다.<br /> CPU %user %nice %system %iowait %idle<br />14½Ã 30ºÐ 01ÃÊ all 32.59 0.01 0.64 2.51 64.24<br />14½Ã 40ºÐ 04ÃÊ all 64.21 0.03 2.82 1.43 31.51<br />14½Ã 50ºÐ 02ÃÊ all 93.84 0.05 4.44 0.09 1.58<br /> <br /> totsck tcpsck udpsck rawsck ip-frag<br />14½Ã 30ºÐ 01ÃÊ 264 71 2 0 0<br />14½Ã 40ºÐ 04ÃÊ 1758 625 2 0 0<br />14½Ã 50ºÐ 02ÃÊ 1744 634 2 0 0<br />15½Ã 00ºÐ 01ÃÊ 72 10 2 0 0<br />15½Ã 10ºÐ 01ÃÊ 1075 372 2 0 0<br />15½Ã 20ºÐ 01ÃÊ 1093 408 2 0 0<br />15½Ã 30ºÐ 01ÃÊ 68 12 2 0 0<br />15½Ã 40ºÐ 01ÃÊ 1749 637 2 0 0<br />

13.
성능 이슈<br />http서버<br />리퀘스트가 한 순간에 몰렸다가 풀리는 상황에서도잘 버틴다.<br /> totsck tcpsck udpsck rawsck ip-frag<br />14½Ã 30ºÐ 01ÃÊ 242 71 2 0 0<br />14½Ã 40ºÐ 02ÃÊ 1123 519 2 0 0<br />14½Ã 50ºÐ 01ÃÊ 250 78 2 0 0<br /> <br /> CPU %user %nice %system %iowait %idle<br />14½Ã 30ºÐ 01ÃÊ all 29.09 0.01 1.25 1.46 68.19<br />14½Ã 40ºÐ 02ÃÊ all 34.84 0.04 1.59 1.40 62.12<br />14½Ã 50ºÐ 01ÃÊ all 33.19 0.02 1.72 1.55 63.52<br /> <br />

14.
SSL Session 설정<br />SSH session cache 를 관리<br />디폴트로 session cache를 쓰지 않는 설정SSLSessionCachenone<br />아니면, SSH session cache를 사용<br />클라이언트에서 cache를 사용하는 경우에 사용 가능<br />Apache 서버의 dbm쓰지 말고, shared memory 쓴다. Cache time은 적당히 지정한다. (당근 성능 테스트하고 결과값을 지정할 줄 알아야 한다.)<br />SSLSessionCache "shmcb:/위치/ssl_scache(512000)"<br />SSLSessionCacheTimeout 300<br />

15.
SSL Session Cache 설정의 조건<br />SSL Handshake를 재사용하기 위해서는 클라이언트측의설정이 필요한데 API의 경우 이런 설정을 안하고 호출을 하기 때문에 캐시 재사용을 안 하게 된다.<br />성능 향상이 없거나, 300초간 저장된 캐시 파일(상황에 다름. 100~200메가 정도의크기)을 정리하는 작업을 Apache가 수행하게 된다. <br />정리하는 작업을 할 때, request를 대기시켰다가 처리되고 나면, 그 결과로 Apache process가 증가하고, Tomcat의 Thread도 증가해서 503 Server Busy가 발생할 수 있다..<br />아예 안쓰는 것도 좋은 방법이 될 수 있다.<br />

16.
성능 이슈 해결 방법<br />Cpu가 많은 중형서버가 아닌 cpu 2개 정도의 싼 서버로 대수를 늘리는 방법<br />SSL 하드웨어 가속기를사용한다. (경험) mpeg codec와 muliplexer와 같이 산수가 많이 들어가는 계산은 하드웨어가 가장 낫다!!! <br />

17.
SSL 하드웨어 가속 테스트<br /> Request 파일 사이즈 별로 성능 확인<br />기억이 안나는데.. SSL 하드웨어 가속기가 달린 장비 설명을 참조함<br />

18.
기타<br />실제 사용<br />EverNote…<br />적용 효과<br />2x~10x<br />서비스의 dependency가 있음 (dB bottleneck)<br />

19.
결론<br />SSL Hardware 가속기가 들어간 L7 스위칭 장비를 활용하면 성능이 좋아짐정말 좋은 것이냐? Https 서비스에 따라서 성능 효과는 달라진다... 테스트는 필요~<br />보수적인 운영, 저렴한 장비로 구축한다면 더 많은 서버 장비로 구축해야 함. 다만, 트래픽이 많은 서비스에는 운영하는데 상당히 귀찮을 수 있음 (배포-재시작/설정 변경때문에 시간이 소요됨)<br />HTTPS 사용은 고객의 정보를 소중히 여긴다는 마인드.<br />