kldp.org는 https 적용하는 이유를 알고 싶습니다.
글쓴이: yellowstone / 작성시간: 수, 2014/11/05 - 8:58오후
금융사이트(모든 금융사이트가 그런건 아니지만...;;) 제외하고 다른 사이트들은 https를 적용안합니다.
그런데 kldp.org는 https를 적용하는 이유가 뭔지 알고 싶습니다.
추후 http/2 적용할 계획도 있으신가요?
Forums:
금융사이트(모든 금융사이트가 그런건 아니지만...;;) 제외하고 다른 사이트들은 https를 적용안합니다.
그런데 kldp.org는 https를 적용하는 이유가 뭔지 알고 싶습니다.
추후 http/2 적용할 계획도 있으신가요?
현재 가진 resource로 SSL 운영을 하는데
현재 가진 resource로 SSL 운영을 하는데 지장이 없기 때문입니다. http/2는 SDPY를 말씀하시는 건가요? SPDY 적용했다가 apache spdy module이 죽어 버리는 문제가 있어 현재 운영하고 있지 않습니다. 나중에 시간이 나서 kldp 서버를 factcgi로 옮기면 그때 다시 적용을 해 볼 생각입니다.
또 다른 이유도 있나요?(보안 측면이나 기타 이유등)
다른 이유도 있는지 알고 싶습니다.
왜냐하면 웹사이트 보안에 잘 모르고, 세상물정(?) 몰라서 알고 싶어서 그렇습니다.
대다수 웹사이트는 https 연결을 사용하지 않고 있습니다. 보안에 무관심해서 그런건지 잘 모르겠지만...
예를 들어 보안 측면에서도 알고 싶습니다.
또한 암호화 연결도 TLS 1.0을 이용하지 않고, TLS 1.2를 사용 하셨는데 그 점도 고려 한건지 알고 싶습니다.
http/2에 관한 것은 SPDY 기반으로 하는 http/2 맞습니다. 아직 HTTP/2는 기술을 공식 배포 전 단계로 알고 있습니다.
추후 2015년 정도에 RFC로 출판될 예정이라고 들었습니다.
일단은 제가 로그인 하는데, 제 정보가
일단은 제가 로그인 하는데, 제 정보가 plain/text로 떠돌아 다니는 것이 싫어서 SSL인증서를 개인적으로 구매해서 기증했습니다. 이게 가장 큰 이유입니다.
국내 포탈에서 SSL을 사용하지 않는 이유는 resource의 문제가 있습니다. L4나 L7의 경우 일반 세션과 SSL 세션의 처리량이 10배 이상 차이가 납니다. 그러므로 모든 세션을 SSL로 처리를 하려면 엄청난 infra 비용이 추가가 되어야 합니다.
TLS 1.2를 사용하는 것으로 보인다면, 사용하시는 브라우저가 지원해서 입니다. 설정상으로는 TSL 1.0 부터 지원합니다. 최근에 Heard Bleed 공격 때문에 SSLv3 는 제외 시켰습니다.
그리고, apache spdy module은 apache pre-fork + mod_php 환경에서는 상당히 불안정 합니다. 3달전에 spdy 모듈을 올렸다가 apache가 죽어서 현재는 지원하지 않고 있습니다.
http/2에 관한 질문입니다.
그럼 http/2 적용하면 SSL 트래픽(?), 부하(?)가 얼마나 줄어들까요?
두번째로 이해가 안가는게 ,http/2 정식 규격이 내년 2월쯤에 나온다고 하는데, 어떻게 http/2를 서버(아파치나 php), 웹브라우저에서 지원을 할수가 있죠?
-
http2 말씀이시라면 정식 규격은 아직 안나왔지만 이의 기반이 되는 spdy자체는 구글에서 개발, 사용중이며 공개 프로토콜이므로 spdy를 지원하는 소프트웨어는 이미 꽤 될 겁니다.
좋은 정보 감사합니다.
최근 Google이나 Facebook 등이 모두 TLS를 사용하면서 TLS 처리 비용이 저렴한 것인가라는 생각을 했는데 그렇지도 않은 모양이네요.
음 ..
모든 세션을 ssl 로 처리하는 것은 특히나 cpu 를 많이 사용하기 때문에...
일반적인 이미지나 동영상 스트림, 평범한 웹 페이지를 모두 ssl 로 처리하는 것은 리소스 낭비죠.
그래서 대신에 로그인이나 결제와 같이 보안이 필요한 일부 세션에만 ssl 을 사용합니다.
ssl 대신 active-x 같은 걸 써서 별도로 세션을 암호화 하거나 하기도 하죠.
잘 안 쓰는고 있는게 아니라 눈에 잘 안 띄는 것 뿐입니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
그럼 구글, 애플, 야후는 https 적용은 어떻게 봐야 할까요?
구글, 애플 이용시 계속 https로 계속 연결이 되고 있습니다.
야후는 적어도 초기화면에는 https로 연결하고 있구요.
아웃룩 메일은 로그인부터 받은편지함 메일 보내기까지도 https로 연결을 하고 있어요.
이들 업체가 https로 연결하는 것은 단지 자금 사정이 좋기 때문에 https를 적용한다고 볼수가 있나요?
두번째로 SSL로 처리하면 CPU에 부하가 일어난다고 하셨는데, 네트워크 장비가 아닌 서버를 말씀하시는 건가요?
2008년 쯤부터 출시된 CPU에 추가된 AES-NI 명령어를 사용해도 부하가 그렇게 높나요?
그리고 AES-NI 명령어 사용하긴 하나요?
인텔 웨스트미어, 샌디브릿지부터 AES-NI를 지원한다고 합니다.
음 ..
ssl 의 사용, 즉 데이터의 암호화는 키생성에서부터 교환, 데이터 암/복호화, 키 관리/파기 등으로 이어지는데..
plain text 에 비해 엄청나게 많은 cpu 자원과, 적당히 많은 메모리를 소모하게 됩니다.
암호화된 데이터 자체는 block size 의 배수보다 작기 때문에, 트래픽에 큰 영항은 없지만 서버 자원(특히 cpu, mem)을 많이 사용하죠.
만약 트래픽이 많은 사이트라면 데이터 암/복호화에 cpu 자원이 많이 소모될 것이고..
TPS(transaction per second) 가 많은 사이트라면 트래픽에 대한 암/복호화도 문제지만, 키 생성에 엄청나게 많은 cpu 가 소모됩니다.
게다가 암호 알고리즘의 종류와 지원하는 하드웨어 가속기에 따라서도 성능이 천차만별..
그래서 사이트의 상황(트래픽, tps, 가용 자원)에 따라 정책을 다르게 가져갑니다.
구글 같은 경우는 텍스트 데이터가 위주니 하나의 트랜잭션에 대한 트래픽은 별로 없겠지만, 전세계 수억의 인구가 접속할 테니..
그 tps 는 ddos 를 넘어설겁니다. 그런데 데이터 센터 같은 클러스터를 구성하던지 해서 로드밸런싱이 되면..
단일 서버당 처리하는 트랜잭션 양이 줄어들고 여유가 있을 테니.. 그까이거 모두 ssl 로 암호화를 해도 되겠죠.
말그대로 사이트마다 자기 상태에 따라 케바케로 운영하는 겁니다.
단지 원칙은 유출되면 안되는 사용자의 credential 이나 개인 정보는 무슨 수를 써서라도 암호화를 해서 기밀성을 유지한다.. 정도..
아웃룩은 imap 이나 pop3 로 어딘가에 접속하겠죠. 아웃룩은 클라이언트기 때문에 지가 ssl 쓰고 싶어도 서버가 안 쓰면 못 씁니다.
해당 메일 서버에서 자기 상황에 맞게 ssl 을 적용하거나 말거나 하는거고.. 그거에 맞춰 아웃룩이 동작하는겁니다.
이메일들은 개인정보에 해당하고, 어딘가로 유출되면 안 되는 엄청 중요한 데이터들이니..
메일 서비스 하는 회사들은 애초에 암호화를 전제로 서비스를 제공하게 됩니다.
그에 맞게 수익 모델을 만들고, 서버들을 확충해서 가용성을 확보하겠죠. 그게 안 되면 뭐 문 닫아야죠..
암호화 안 하면 개인 정보 유출로 어차피 회사 문닫을 거고.. 서버 확충 안 되면 다들 느리고 용량 없다고 다른 데 갈텐데...
끝으로, AES-NI 는 잘 모르겠지만, 특정 암호화 알고리즘을 cpu 에서 지원하는 기능이라고 가정하면..
어차피 다른 알고리즘 쓸 때에는 무용지물이고, 애초에 부하가 걸리는 상태에서라면 약간 덜 느린 정도에 불과한 거라..
단일 cpu 성능에 의존하는 것은.. 흠.. 저라면 부득이한 경우를 제외하고는 별로 기대하지는 않을 것 같네요.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
저 아웃룩 메일이 그 메일이 아닙니다;;
답변 감사합니다.
오해 하신부분이 좀 있습니다.
아웃룩 메일은 아웃룩 클라이언트 말하는게 아니고 웹메일 서비스 outlook.com을 가리키는 거였습니다.;;
제가 말하고자 하는 AES-NI 명령어는 단일 CPU로 사용할 경우 말하는게 아닙니다. 서버처럼 구성해서 AES-NI 명령어를 사용하자는 얘기 였습니다.
성능 2011년도 기사
"전 세대에 해당하는 제온 7500과 E7 시리즈를 직접 비교를 통해 인텔 AES-NI 보안 기술에 대한 성능 시범도 선보였다. 암호화된 6000만 건에 달하는 데이터를 복호화하는 작업에서 제온 7500 프로세서는 11.42초가 걸린 반면, 인텔 제온 프로세서 E7 시리즈는 는 절반 정도에 해당하는 5.98초가 걸렸다."
http://www.bloter.net/archives/56105
지원 알고리즘은 AES만 지원하는 것 같습니다. 다른 알고리즘에서는 효과가 없겠네요....
음 ..
outlook.com 이란 웹메일 서비스가 있었군요..;;
그래도 어쨌든 완전 헛소리를 적어 놓은 건 아닌 것 같아 다행이네요..;;
AES-NI 는 지금 나와있는 많은 CPU 에 적용되어 있군요.
http://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs
OpenSSL 같은 암/복호화 라이브러리에서 특정 암호 알고리즘이 CPU 와 관련된 어셈 코드로 최적화 되어 있다면..
굳이 의식하지 않더라도 자연스럽게 CPU 의 암호화 관련 instruction 을 사용하고 있는 상태일 겁니다.
찾아보니 1.0.1 부터 지원한다네요. AES 말고도 지원되는 알고리즘이 더 있을 것 같네요.
https://software.intel.com/sites/default/files/open-ssl-performance-paper.pdf
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
TLS에 관심이 많으신 것 같은데
다음 blog를 읽어보시면 궁금한 점이 많이 해결될 것 같습니다.
https://www.imperialviolet.org/
Adam G. Langley라고 Google Chrome의 보안부분을 담당하는 사람이 쓰는 blog입니다. 최근 HeartBleed나 POODLE Attack 등 모두 그를 포함한 Google 보안팀의 발견에서 시작되었습니다. 학자는 아니고 기술자니까 보안과 암호화 분야에서 많이 알려진 이름은 아니겠습니다만 최근 들어 직접 RFC도 작성하고 활발하게 작업하더군요.
AES-NI를 적극적으로 쓰게 된 것은 제가 보기에는 작년 그러니까 2013년 하반기부터였습니다. 그리 오래 되지 않았죠. OpenSSL 1.0.1을 쓰고 있지 않다면 모두 적용되지 않을 겁니다. 또한 AES-NI는 최근 대세라고 할 수 있는 SmartPhone에서는 적용되지 않기 때문에 그걸로 TLS 암호화 연산비용이 전부 해결된다고 볼 수 없습니다. 그래서 Adam Langley가 직접 ChaCha20-Poly1305라는 Daniel J. Bernstein 교수가 만든 stream 암호를 도입하고, RFC를 작성하더군요.
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
현재 Chrome하고 Opera에서만 AES-NI를 쓰지 못하는 경우 이 stream 암호화를 쓰더군요.
관련성능은 https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html 에서 볼 수 있습니다.
그의 의견에 의하면 TLS 비용은 더이상 비싸지 않다고 합니다.
https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
https://www.imperialviolet.org/2011/02/06/stillinexpensive.html
그러나 이것은 정상적인 운용에 대한 것이고 DDoS attack은 얘기가 달라지죠.
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20111026101742
기사내용이 멍청한데 2011년 당시 laptop 1대로 TLS의 연산비용이 비싼 점을 이용해 DDoS를 성공시켰다는 이야기인데 원래 DDoS라는게 운영자가 잘 관리해서 방어해야 하니까... ^_^.
그런데 김정균님 말씀에서 L7은 몰라도 L4에서 처리 과부하가 생기는 이유는 모르겠네요.
L4 장비도 ssl을 지원을 하는 제품이 있는데, 이
L4 장비도 ssl을 지원을 하는 제품이 있는데, 이 성능이 일반 세션의 1/10 정도 밖에 보장을 하지 않는 것이 문제죠. :-)
TLS 비용이 더이상 비싸지 않다고 하는 것도 기술적인 문제일 뿐이고 체감적으로 현재의 제품군에서는 여전히 비쌉니다. 구글이 SPDY를 만든 이유도 TLS 비용이 비싸기 때문에 만들었겠죠. (위의 글을 읽어보지 않아서 TLS 비용이 비싸지 않은 이유중에 SPDY가 들어가는지는 모르겠지만.. ^^)
다만, SPDY가 모든 SSL 세션에 대해서 부하를 줄여주지 않는다는 것이 문제이기는 합니다. SPDY는 keep alive를 최대한 활용할 수 있는 서비스나 설계 구조에서 성능을 높여주는 것으로 보이더군요. (저도 SPDY에 대해서는 자세하게 분석을 하지 않은 상태이므로 제 의견이 틀릴수도 있습니다.)
저는 반대라고 생각합니다.
SPDY는 항상 TLS 위에서 동작합니다. 그것은 TLS의 암호화 비용이 문제가 되지 않는다고 보았기 때문이라고 봅니다.
SPDY는 TLS 위에서 round trip 위주의 성능문제를 해결하기 위해서 만든 것으로 압니다.
저는 network 장치는 거의 모르는데 Intel CPU를 쓰는 경우도 많은 것 같더군요.
최신의 Intel CPU를 쓴다면 AES의 경우 가속을 통한 성능향상을 얻을 수 있을 것 같네요.
http/2 관련 내용 보다가 들어왔는데...
저처럼 뒤늦게나마 보실 분들을 위해 제 지식을 남겨 봅니다.
반대 당하신(?) 분도 맞는 말씀을 하셨고, 반대하신 분도 맞는 말씀을 하셨습니다.
TLS 암호화라는 한 단어로 묶여서 논의가 진행이 되어 그렇습니다.
TLS의 암호화 과정은 사실 두 단계이고 특성이 매우 다릅니다.
- 처음에 접속을 맺고 대칭키를 교환하는 과정
인증 및 키교환 과정에서 2번의 라운드 트립이 추가됩니다(=초기 응답 지연). CPU비용도 큽니다.
- 이후 통신 과정
암호화/복호화를 하는데에 첫 단계에서 교환한 대칭키를 활용합니다. CPU비용이 작습니다.
round trip은 비용은 아예 없습니다. 암호화 안 했을 때에도 원래 오고 갈 내용이 바뀐 것입니다.
네트워크 장비의 세션수 한계 등은 비싼 1단계를 쌩으로 감당할 때의 CPU비용으로 보시면 될 것 같습니다.
2단계는 1단계에 비해 상대적으로 매우 저렴합니다. 게다가 말씀하신 AES-NI를 쓰면 더 낮아집니다.
SPDY는 접속 한 번에 여러 번 요청하고 결과를 받을 수 있게 합니다.
즉, 접속 맺는 횟수를 줄입니다. 따라서 TLS의 "비싼 1단계 과정이 상당수 생략되어" 성능이 올라갑니다.
예를 들어 웹페이지 하나에 그림이 9개인 페이지를 생각하면...
기존에는 커넥션을 10개 맺어야 했습니다. 암호화 1단계도 10번합니다. (실제론 좀 다릅니다만, 예시니까...)
SPDY는 1개만 맺고 html, 그림9개를 다 받을 수 있게 하는 프로토콜입니다. 암호화 1단계는 1번만 합니다.
CPU 많이 먹는 과정 9개가 생략되는 것이지요. 또한, 라운드 트립 18번이 사라집니다. (라운드 트립은 사실 또 좀 다른 얘기가 있습니다만...)
round trip "time"은 물리적, 지리적으로 존재하는 어쩔 수 없는 것이기에 round trip 횟수를 줄이면 초기 응답시간이 짧아집니다.
2010년대 들어서는 TLS의 초기 단계의 CPU 비용도 큰 문제가 아니라고 하는 정도가 되어 SPDY의 round trip 줄인 부분이 더 강조가 되는 것 같습니다.
물론 TLS 초기 단계의 암호화 비용은 여전히 암호화 안 하는 것보다는 훨씬 비싼 비용은 맞습니다.
추가로...
SPDY는 TLS 위에서 동작할 수도 있고, 안 할 수도 있습니다. (http에도 SPDY를 쓸 수 있습니다)
마지막으로...
http/2가 표준이 되었고 SPDY는 중단되었지만, 큰 맥락은 비슷하니 SPDY로 표기했습니다.
김정균님 같이 보안에 신경 쓰는 관리자 분이 있으시고
김정균님 같이 보안에 신경 쓰는 관리자 분이 있으시고 그에 필요한 자원도 있으니 https로 운영되는 것이라 짐작 합니다.
댓글 달기