평문 데이터 전송 이슈 - mtjddnr/lab GitHub Wiki

https://www.facebook.com/groups/codingeverybody/permalink/704415879598951/ 글에서 나온 정보를 토대로 제 지식 + 검색으로 정리한것입니다. (대화 내용중 기사의 정확성 유무를 가리는 내용은 제외했습니다.)

평문 데이터 전송 이슈

발단

카드사 개인정보 유출사건 http://mirror.enha.kr/wiki/%EC%B9%B4%EB%93%9C%EC%82%AC%20%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4%20%EC%9C%A0%EC%B6%9C%EC%82%AC%EA%B1%B4

허술한 유출확인

암호화가 되어 있는가?

내용은 볼 수 있는데 내용이 암호화 되어 있느냐의 여부가 중요한거죠... (Hanssem Chang)

HTTP?

http://ko.wikipedia.org/wiki/HTTP

WWW 상에서 정보를 주고 받을 수 있는 프로토콜

GET? POST?
- 전송 방식은 보안과 관계 없음
  
  전송 method가 GET이나 POST냐는 중요한 요소가 아니라고 봅니다. http로 전송했으면 암호화를 했어야 하고, 평문으로 보낼거면 https로 보냈어야 안전한건데 아무 조치를 안했다는게 문제겠죠. 여러가지 방법이 있음에도 결국은 암호화 하지 않고 평문으로 보냈다로 요약할 수 있을겁니다. (Sunchan Lee)
  
  GET POST 메소드 랑 아무 상관이 없습니다. 그냥 평문으로 보낸것이 중요한것이죠 (박찬주)
GET은 페이지 요청시, POST는 폼 데이터(개인 정보나 글을 쓸때)전송시 사용
- GET의 경우 브라우져 기록에 남기 때문에 폼 데이터 전송에 사용하면 발생하는 사례
음.. get방식으로 폼 데이터를 넘긴덕에 한 때 다음이 피씨방에서 단순 히스토리 확인만으로 신나게 아이디, 비번이 유출 된 사례가 있었다는 것을 본적이 있습니다. (이형돈)

HTTPS?

HTTPS와 SSL 인증서 http://opentutorials.org/course/228/4894

HTTPS와 SSL를 같은 의미로 이해하고 있는 경우가 많다. 이것은 맞기도 틀리기도 하다. 그것은 마치 인터넷과 웹을 같은 의미로 이해하는 것과 같다. 결론적으로 말하면 웹이 인터넷 위에서 돌아가는 서비스 중의 하나인 것처럼 HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜이다.
http://ko.wikipedia.org/wiki/HTTPS

HTTP의 보안이 강화된 버전

SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다.

HTTPS를 사용하는 웹페이지의 URL은 'http://'대신 'https://'로 시작한다.
HTTPS는 SSL/TLS로 접속해서 내용은 HTTP로 보내는 구조

https쓰면 프록시 써도 안됩니다. 내용을 보기 위해서는 암호를 풀어야하는데, 풀기 위한 암호는 웹서버만 갖고있거든요. 그걸 임의로 풀려면 애초에 브라우저에게 본인이 해독할 수 있는 암호키를 전달해야하고, 이건 정식 인증서가 없으므로 웹브라우저가 경고를 해 줄 수 있지요. (Sungkwang Lee)

프록시를 사용해서 https가 도청되는 케이스는 아래 SSL MITM을 참고해주세요.
웹 브라우져가 경고 한다는것 (http://opentutorials.org/ 참고)

사설 인증기관

개발이나 사적인 목적을 위해서 SSL의 암호화 기능을 이용하려한다면 자신이 직접 CA의 역할을 할 수도 있다. 물론 이것은 공인된 인증서가 아니기 때문에 이러한 사설 CA의 인증서를 이용하는 경우 브라우저는 아래와 같은 __경고__를 출력한다.

공인된 CA가 제공하는 인증서를 사용한다면 브라우저의 주소창이 아래와 비슷한 모양을 보여줄 것이다.

보통 회사에서 인터넷 쓸 때 저런 인증서 오류가 자주 뜨던데, 이런게 뜬다면 회사에서 다 검열하고 있다는 이야기가 됩니다(...) 여튼 최소한 https를 쓰면 서버사이드에서 털려서 암호키가 새지 않는 한 중간에 누가 보기는 매우 어려워진다는 이야기입니다. (Sungkwang Lee)

...그렇지만 만약 (이런 일은 거의 없을것이라고 믿습니다만...) Certificate Authority 가 뚫렸거나 나쁜 의도로 가짜 certificate 를 싸인해줬다면...얘기가 다르죠ㅎㅎ (Doomari Dev)

CA?

Certificate authority

인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 한다. 이 역할을 하는 민간기업들이 있는데 이런 기업들을 CA(Certificate authority) 혹은 Root Certificate 라고 부른다. CA는 아무 기업이나 할 수 있는 것이 아니고 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다. 그 중에 대표적인 기업들은 아래와 같다. (위키피디아 참조)

상상 했던 것 보다 https의 인증서를 유지 하는 체로 내용을 가로첸다거나 하는것이 어려운가보군요(...) 왠지 외국은 별다른 엑티브엑스의 도움 없이 https만으로 보안정보를 주고받는게 납득이 가고있습니다. (이형돈)

HTTPS가 암호화 하는 유일한 방법은 아니다?

http를 쓰든, https를 쓰든 무슨 상관입니까 암호화만 되면 되죠 ㅎㅎ 제가 본 기사에서는 A사이트는 평문으로 보내고 있었고, B 사이트는 암호화는 되어 있었으나 평문으로 되어 있었다고 적혀 있더군요. 그 말인즉슨, 둘 다 https를 안썼다는 이야기인데 일반인 입장에서는 프로토콜 이름보다 어떻게 전송되느냐가 더 중요하겠죠. 굳이 https란 이름이 안나와도, 암호화 된 문장이 보내지느냐, 평문이 보내지느냐로 얼마든지 표현 가능한 내용입니다. 심지어 POST는 암호화도 아니고 평문이구요.

애초에 우리나라에서 쓰는 세션 보안용 플러그인은 암호화된 내용을 평문으로 전달할텐데요 뭘..

암호화 하는 방법이 https밖에 없는것도 아닌데요 뭘.. 맨날 깔라는 activex 방식으로 이루어지는 xecureweb이라던가 하는거도 https 없이 나름 암호화해서 보내는걸로 알고있어요. 이런거 써도 될 문제긴 하지요. (Sungkwang Lee)

HTTPS를 사용하지 않고 데이터를 보내더라도 암호화만 하면 된다.
ActiveX기반 암호화 플러그인
- HTTP상에서 폼 데이터를 암호화 모듈을 거쳐서 암호화 시킨후 전송하는 기법
참고 대한민국의 웹 호환성 문제

전자상거래 암호화 기술

원인의 시초는 전자상거래 암호화 기술로부터 시작되었다. 과거 2000년까지는 미국 정부가 미국판 인터넷 익스플로러에는 128비트 수준의 고수준 암호화 기술인 SSL 보안 접속을 허용했으나 미국을 제외한 수출용 인터넷 익스플로러는 40비트 이상의 보안 접속을 하지 못하도록 __금지__해 왔다. 1990년대 후반 대한민국에서 초고속 인터넷망이 확산되면서 다양한 은행거래와 카드 결제 서비스가 생겨나 보안위협이 대두되자 정보통신부 산하 기관인 한국정보보호진흥원에서는 독자적인 128비트 대칭키 블록 암호화 알고리즘 SEED를 __개발__하였고 이를 웹 브라우저에 간편하게 탑재하기 위하여 인터넷 익스플로러에서만 작동하는 ActiveX를 사용하였다. 이는 곧 국내 표준이 되어 금융감독원은 이 기술을 전자상거래를 위한 보안성 심의 기준으로 삼았다. 이로 인해 ActiveX는 대한민국 인터넷 환경에서 폭발적으로 확산되게 되었다. 하지만 2000년대 이후 128비트 암호화 기술을 사용하는 SSL의 수출 제한이 __해제__되어 SSL이 로열티를 지불하지 않는 국제 표준으로 인정되면서 대부분의 웹 브라우저와 국가의 전자상거래 체계가 이 기술을 채택하게 되었으나 대한민국은 이미 SEED를 ActiveX로 개발하여 사용해왔기에 계속 사용하게 되었다.
요약
- 미국이 SSL기술 수출 금지
- 그래서 정부가 직접 ActiveX기반으로 보안 기술(SEED) 개발
- 그러나 미국에서 SSL기술 수출 금지 해제 및 표준으로 채택
- 국내에서는 기존 기술 계속 사용
nProtect, 제큐어웹(XecureWeb)

파로스?

파로스는 웹 트래픽 분석툴입니다. proxy긴 한데 목적이 내용을 보는 목적의 proxy입니다ㅋ (Sungkwang Lee)

그래서 https 를 보려고 http://mitmproxy.org/ 같은게 나왔어요ㅎㅎ (*물론 이걸 통해서 들어가시면 원래 도메인을 쓰시면 가짜인증서라고 뜨죠) (Doomari Dev)

리눅스 기반 패킷 분석 툴 http://mitmproxy.org
- 정리글 https://github.com/mtjddnr/lab/wiki/MITM-Proxy

통신 도청 이슈

http를 사용하면 서버와 클라이언트간의 데이터를 평문으로 전송합니다. 따라서, 중간의 데이터를 볼 수 있는 컴퓨터는 데이터를 볼 수 있지요. 예를들어 ap에 접속되어 있는 경우에는 그 ap에 접속되어 있는 모든 컴퓨터에 브로드캐스팅 되기 때문에 데이터를 볼 수 있습니다. (와이어 샤크같은 패킷 스니퍼를 통해서 잡을 수도 있구요 더 중요한것은 서버와 클라이언트간의 프록시서버(WAS 등)에 로깅될 수도 있습니다. ) 이것을 데이터 스니핑 또는 도청이라 합니다. 이런 전송 레이어에서의 보안(기밀성, 무결성)을 제공하기 위해 보통 https를 사용합니다. (Seung Je Park)

카페같은 오픈 공간에서 제공되는 공용 WiFi를 사용하면 중간자가 흘러가는 데이터를 도청할수 있다.
- 도청해서 데이터가 보이더라도 그 데이터가 암호화 되어 있으면 된다.
HTTP로 암호화 없이 보내면 내용이 다 보인다.
HTTPS로 하더라도 mitmproxy에서 제공되는 가짜(?) 인증서를 설치한다면 도청이 가능하다. (ssl mitm 해킹 기법)

SSL MITM?

Man-in-the-middle attack
참고 http://superuser.egloos.com/3183253

공격 시나리오는 이렇습니다.

Attacker는 Victim 에게 DNS Spoofing 을 이용하여 자신을 주소를 Server의 주소인것처럼 속입니다.

Victim 으로부터 서버로의 패킷을 릴레이 합니다. (Victim은 접속이 아무 이상 없이 잘되므로 통신을 합니다)
로그인시 Server로부터 SSL통신을 위한 인증서가 송신되고 Attacker는 Server의 인증서를 저장합니다.
Victim에게 Attacker의 인증서를 송신합니다.
Victim은 Attacker의 인증서를 승인하게 되고 Attacker의 공개키로 암호화 된 패킷은 해독되게 됩니다.

요약
- 공격자가 피해자 컴퓨터의 DNS정보를 해킹
  - 피해자가 맞는 사이트 주소를 입력하더라도 공격자가 유도한 IP의 서버로 접속하게 된다.
  - 공격자의 서버가 대신 원래 서버에 접속해서 데이터를 전달한다.
  - 피해자는 사이트가 제대로 접속된다고 착각.
  - 공격자는 피해자의 통신 정보를 고스란히 받는다.
  - 이때 피해자의 브라우져에서 인증서에 문제가 있다고 경고
  사용자는 대부분 아무 생각 없이 예를 클릭한다는것이 문제가 됩니다.
기업에서 정보 보안을 위해 인트라넷에서 외부 인터넷으로 접속할때 감청

보통 회사에서 인터넷 쓸 때 저런 인증서 오류가 자주 뜨던데, 이런게 뜬다면 회사에서 다 검열하고 있다는 이야기가 됩니다(...) 여튼 최소한 https를 쓰면 서버사이드에서 털려서 암호키가 새지 않는 한 중간에 누가 보기는 매우 어려워진다는 이야기입니다. (Sungkwang Lee)

질문자님의 질문에 답해보자면 https를 통해 데이터를 전송할 때에 proxy를 통한다면 그 데이터는 proxy에서 볼 수 있습니다. 단, proxy에서 신뢰할 수 있는 인증서를 제공해야 합니다. 브라우저에는 신뢰할수 있는 인증서인 root ca certificate 가 설치되어 있는데 root ca 인증서가 인증하는 인증서가 proxy에서 제공한다면 그 프록시를 통하여 데이터를 볼 수 있습니다. 그 반대로 proxy에서 신뢰할 수 없는 인증서를 제공한다면 클라이언트의 브라우저에는 신뢰할 수 없다고 __빨간 경고창__이 나오게됩니다. 도움 되셨으면 좋겠네요 (Seung Je Park)

박승제 궁금한 점에 대한 답변 감사합니다. 그럼 결국 해킹 목적으로 proxy를 거치게 하는 악성코드에 __감염되었다면 https를 써도 유출__이 가능 하다는 것이군요. (이형돈)

@박승제 님이 말한것는 ssl mitm 이라는 방식입니다 __가짜인증서를 이용한 해킹 공격__이죠 Ssl strip 이라는 공격을 이용하면 좀더 티안나게 공격을 시도 할 수가 있습니다 (박찬주)

SSL Strip?

포털 사이트 들도 불과 2년 전만해도 ssl strip 공격에 계정과 패스워드가 노출되곤했죠 (박찬주)

ssl strip은 홈페이지 내용을 읽다가 https가 나오면 http로 바꿔서 보내주는 공격입니다. (Sungkwang Lee)

SSL Strip도 MITM공격 아닌가요? Fiddler같은 디버거툴은 가짜 인증서를 사용하는 방법을 쓰고, SSL Strip 기법은 https를 http로 바꿔치기하는 방식의 차이 아닌가요?

SSL Strip 공격은 애초에 https를 http로 조작하지 못하게 하면 될듯하네요.

개인정보 입력하는 폼에서부터 서버에 정보를 제출하는 모든 부분을 서버에서 https 요청인지 체크하고 아니면 그냥 튕겨버리면 될 거 같아요

SSL이 뚫리고 패킷을 위/변조 할수있는 상황이라면, ActiveX를 쓰던 개인정보를 RSA암호화를 하던 털릴듯하네요.

개인정보를 암호화한다면 해커가 그 암호화 script를 제거해서 클라이언트에게 넘긴다거나, 엑티브엑스를 쓴다면 엑티브엑스를 사용하지 않는 악성파밍사이트로 유도해서 개인정보를 탈취하면 될듯하네요

여튼 HTTPS(SSL)를 사용하지 않거나 MITM공격으로(Fiddler방식이나 SSL Strip공격으로) SSL이 무력화된 통신이라면 ActiveX를 사용하는 건 개인정보를 암호화하건 전혀 의미가 없지 않을까요? (김동현)

Ssl strip 도 mitm 공격 맞습니다 단지 ssl mitm 가짜인증서를 이용한 방법과 구분하기 위해서 언급한것이죠 (박찬주)

참고 http://blog.naver.com/PostView.nhn?blogId=addong1224&logNo=120169262049

SSL MITM 의 변종 형태로 SSL-https 에서 http로 s를없애고 통신하게 만들어 사용자의 중요 정보를 열람 하는 기법 [출처] SSL Strip|작성자 강준희

요약
- SSL MITM과 마찬가지로 공격자가 피해자와 서버의 중간에서 통신을 감청하는 기법이지만 인증서 오류 메세지를 피하기 위한 변종 기법
- 피해자가 사이트에 접근하면 공격자 서버에서 https로 된 모든 링크를 http로 치환해서 돌려준다.
- 피해자가 접근하는 주소가 원래 https라면 공격자 서버에서 대신 원래 사이트 서버에 https로 접속한다.
- 이 경우 피해자가 보는 사이트는 https가 전혀 없다. (경고도 안뜬다)

김동현 "서버에서 https 요청인지 체크하고 아니면 그냥 튕겨버리면 될 거 같아요" <-- 문제는 튕기기 전에 이미 mitm한 중간애가 알아서 처리한 경우라면 얘기가 다르죠 (이미 세어나갈건 세어나간경우죠...) (Doomari Dev)

김동현 그냥 phishing 서버를 같은 도메인으로 운영하는거(?) 라고 생각하시면 되요ㅎ (Doomari Dev)

Doomari Dev 처음부터 __파밍사이트__로 이동시켜버리면 답이없죠 ㅋㅋ 근데 그건 100% 사용자 책임 아닌가요? 유저의 네트워크가 해킹당한걸 막을순 없으니까요 (김동현)

김동현 물론 그렇게 보실수 있지만... 그래도 궁극적인 SSL 쓰는 목표 자체가 이런것까지 막는것 아닌가요? 물론 저한테도 이건 gg 이긴 하네요ㅋㅋ (Doomari Dev)

Doomari Dev 파밍은 서버에서 해줄수 있는 방법이 전혀 없어요. 유저의 피시가 좀비감염되서 개인자료가 유출됬을때, 그 책임이 유저에게 있는것과 같죠. 물론 그것까지 차단하려고 ActiveX를 사용하긴하죠. 그런데 파밍공격을 하면 애초에 ActiveX가 실행될 기회조차 없으니 그것도 소용이 없죠. (김동현)

피싱? 파밍?

http://ko.wikipedia.org/wiki/%ED%94%BC%EC%8B%B1

컴퓨팅에서, 피싱(phishing)은, 전자우편 또는 메신저를 사용해서 신뢰할 수 있는 사람 또는 기업이 보낸 메시지인 것처럼 __가장__함으로써, 비밀번호 및 신용카드 정보와 같이 기밀을 요하는 정보를 부정하게 얻으려는 social engineering의 한 종류이다. ‘피싱’(phishing)이란 용어는 fishing에서 유래하였으며 private data와 fishing의 합성어이다[1] (phreaking에서 영향을 받았을 것으로 추정)[2][3], 즉 점점 더 복잡한 미끼들을 사용해서 사용자의 금융 정보와 패스워드를 ‘낚는’다는 데서 유래되었다.

http://imbiz.tistory.com/74

피싱(phishing) 은 사용자가 SMS나 이메일을 통해 가짜 홈페이지로 접속을 __유도해서 정보를 탈취__하는데 반해,

__파밍(Pharming)__은 사용자의 컴퓨터에 __악성 프로그램__을 몰래 설치해놓고, 정상적인 금융사이트 __접속시에 임의의 가짜 사이트로 접속__을 시킵니다. 사용자는 처음에 본인이 원하는 금융사이트로 접속했기 때문에 중간에 바뀐 가짜 사이트로 가는 걸 눈치 채지 못하고, 개인정보를 입력하게 되면 금융사기단에 당하게 됩니다.

참고 http://imbiz.tistory.com/167

파밍은 아래와 같은 흐름으로 이루어져 있습니다

해커가 "이용자"의 PC에 악성코드 배포

"이용자"가 정상적인 사이트 접속

"악성코드"는 "위조사이트"로 이동

위조사이트에서 "금융정보" 절취

요약
- 사기단등에 의해 낚시질 당하는것
- 웹사이트 서비스 제공자가 할수 있는것이 없다.
  
  Doomari Dev 파밍은 서버에서 해줄수 있는 방법이 전혀 없어요. 유저의 피시가 좀비감염되서 개인자료가 유출됬을때, 그 책임이 유저에게 있는것과 같죠. 물론 그것까지 차단하려고 ActiveX를 사용하긴하죠. 그런데 파밍공격을 하면 애초에 ActiveX가 실행될 기회조차 없으니 그것도 소용이 없죠. (김동현)

Doomari Dev 서버에 접속했을때 올바르게 SSL인증서가 보이느냐로 파밍사이트인지 진짜 사이트인지 구분할 수 있는데, 그걸 확인하지 못한다면 유저의 책임이죠. (김동현)

김동현 근데 그런 인증서니 뭐니 하는거 아는 분에게는 유효하지 않은 인증서 메시지가 의미 있겠지만 사실 유효기간 지나도 쓰는 곳이 있고, 나이드신 분에게는 그런게 큰 부담이긴 하죠..orz (이형돈)

뭐 그래도 서비스 제공자가 할 수 있는 최선의 방법은 SSL이 아닐까 싶네요ㅋㅋ (김동현)

유효기간 지난 인증서는 쓰면 안됩니당;; 원래 인증서 경고가 뜨면 접속을 안해야하는게 맞는데, 우리나라에서는 국내전용 root CA쓰는데도 많아서 위변조 방지가 약하죠.. (Sungkwang Lee)

모든 사이트를 HTTPS로?

김동현 그렇죠 ㅎㅎ 개인 홈페이지 운영자라면 인증서 값이 부담이고(그래서 멤버 수 몇명 이상이여야 필수라고 제한 하는 듯 합니다.) 무조건 강제하긴 좀 무리가 있지만, 서비스 제공자라면 인증서 값을 아깝다고 아끼지 말고 중요한 정보, 아니면 모든 페이지가 HTTPS 상에서 서비스 되어야겠죠. 뭐.. 사실 사용자 수와 서버 사양에 비해 HTTPS의 암호화 때문에 걸리는 부하가 많다면 개인정보가 오고 가는 곳에서만 HTTPS를 쓰는 것도 나쁘지 않죠. (절충안이라 봐야겠죠?) 생각 해 보면 트위터 서버는 모든것이 HTTPS상에서 서비스를 재공하니 참... 어마어마 하겠네요(.....) (이형돈)

그리고 개인정보만 https를 쓰도록 했을때의 문제는, 여러가지 이유로 페이지가 변조됐을 때 https를 전부 없애고 똑같이 생긴 http로 접속된 경우를 확인할 수 있는 방법이 오직 '주소창에 자물쇠가 있는지 확인하는 방법'밖에 없다는게 문제입니다. 서버 여력이 충분하다면 전체를 다 https로 싸는게 제일 안전하긴 하죠. (Sungkwang Lee)

하지만 유효기간 지났어도 쓰는 곳이 있다는 것이... 문제인 것이죠 ㅎㅎ;; 추가로, 여력만 된다면 모두 https를 써야 좋다는건 동의합니다. (이형돈)

사이트 전체를 HTTPS로 지원하게 되면 서버 부담, 즉 돈이 든다.
절충안으로 개인정보가 사용되는 부분(로그인, 가입 등)만 HTTPS사용
- 이경우 SSL Strip 공격에 취약하다.
최고는 사이트 통째로 HTTPS지원하는것 예) 트위터

HTTP 2.0?

http://html5experts.kr/archives/727

또한, __SPDY__는 통산을 시작할 때 TLS의 NPN(Next Protocol Negotiation: TLS세션을 확립하기 위한 최초 통신을 할 때 해당 통신에 이용하는 프로토콜을 명시하는 것으로 1개의 접점에 여러 프로토콜에 의한 통신을 대기하도록 하는 기술)확장을 사용하고 TLS세션을 확립할 때 기존 HTTP를 사용할지, SPDY를 사용할지를 결정한다. 이런 이유로 현재 SPDY는 TLS를 사용하는 것을 사실상 전제로 하고 있어 HTTPS이외로는 이용할 수 없다.

Mark Nottingham에 의하면 이 부분에 대해서 __HTTPS만으로 HTTP/2.0을 이용할 수 없는 상황은 생각할 수 없다__고 밝히고 있어, TLS를 이용하지 않는 통신 사양은 새롭게 책정될 것이다. 이 점에 대해서도 HTTP URL에 네고시에이션 하는 방법에 대한 검토가 기재되어 있다. 메일링 리스트에 대해서는 DNS의 SRV레코드를 이용하는 방법등이 포함되어있고 기존 HTTP/1.1에 준비되어 있는 Upgrade헤더를 이용하는 방법을 제안하고 있다.

http://www.itworld.co.kr/news/84809
차세대 HTTP규격에 보안을 전제로 하려는 움직임

SPDY?

http://helloworld.naver.com/helloworld/140351

SPDY의 특징을 간단히 살펴보자.

항상 TLS(Transport Layer Security) 위에서 동작

따라서 HTTPS로 작성된 웹 사이트만 적용 가능하다.

TLS는 SSL(Secure Sockets Layer)의 다음 버전이다. 같은 프로토콜의 예전 버전 이름과 현재 버전 이름이므로 종종 혼동되어 사용되며, 이 기사에서도 TLS와 SSL을 구별해서 사용하지는 않는다.

왜 TLS를 필요로 하는가?

TLS 사용으로 인해 암호화/복호화 작업으로 인한 전송 지연이 발생함에도, 왜 SPDY는 TLS를 사용하고 있는가? 이 질문에 대해 Google의 SPDY Whitepaper에서는 다음과 같이 이유를 밝히고 있다.

"장기적으로 보아 웹 환경에서 보안성은 점점 더 강조될 것이므로, SPDY의 __하위 프로토콜로 TLS를 지정__하여 향후 더 __나은 보안성__을 얻고자 한다.

현재 네트워크 인프라와의 호환, 즉 기존의 프록시를 거치는 통신과 호환성 문제가 발생하지 않도록 하기 위해 TLS가 필요하다."

이와 같은 이유가 있으나, 실제 SPDY의 구현을 살펴보면 TLS의 NPN(Next Protocol Negotiation) 확장 기능에 SPDY가 크게 의존하고 있음을 알 수 있다. 이 TLS NPN 확장은 서버의 443 포트로 들어온 요청이 SPDY인지 여부 및 요청에서 사용하고 있는 SPDY 버전을 판별하여 이후의 통신을 SPDY로 처리할지 판단할 수 있게 한다. 만약 TLS NPN이 없다면 SPDY 사용을 위해 추가적인 RTT(round-trip time)가 필요할 것이다.

마무리

평문 데이터로 까인 이유: 보안 문제로 한번 털렸는데 제공한 유출 확인 페이지의 허술한 보안

무엇이 논의되고 무엇이 더 중요한지는 잘 모르겠지만 개인적으로 http/https, GET/POST 보다는 암호화를 시켰느냐 평문이냐가 더 중요한것 같습니다...그리고 가장중요한점은 농협은 그 어느것도 하지 않았다는것 아닐까요?? (Kim Sun Min)

@김선민 그렇죠. 아무것도 안했다는 것. 이게 가장 크죠. 단지, 무엇이 아쉬운건지를 알리려 쓴 글입니다 ㅎㅎ.. (또한 기왕이면 농협의 문제를 오해 없이 이해 하길 바라는 것이 있습니다.) (이형돈)