나에게 던지는 질문 - 1

22. 보안에서 해싱 함수란?

-> 해쉬함수(Hash Function)는 임의의 길이를 갖는 메시지를 입력하여 고정된 길이의 해쉬값을 출력하는 함수입니다. 현재 사용되고 있는 SHA-1과 같은 표준 해쉬함수들은 160비트 내지 256비트의 해쉬값을 출력합니다. 암호 알고리즘에는 키가 사용되지만, 해쉬함수는 키를 사용하지 않으므로 같은 입력에 대해서는 항상 같은 출력이 나옵니다. 이러한 함수를 사용하는 목적은 입력 메시지에 대한 변경할 수 없는 증거값을 뽑아냄으로써 메시지의 오류나 변조를 탐지할 수 있는 무결성을 제공하기 위해서 입니다.

 해쉬함수는 전자서명과 함께 사용되어 효율적인 서명 생성을 가능하게 합니다. 긴 메시지에 대해 서명을 하는 경우, 전체 메시지에 대해 직접 서명을 하는 것이 아니고 짧은 해쉬값을 계산해 이것에 대해 서명을 하게 됩니다. 공개키 연산은 많은 계산량을 필요로 하기 때문에 전체 메시지를 공개키 길이의 블록 단위로 나누어 모든 블록에 서명을 하는 것은 매우 비효율적입니다. 그러므로 먼저 메시지를 입력하여 160비트 내지 256비트의 짧은 해쉬값을 계산하고, 이것에 대해 한 번의 서명 연산을 합니다. 이 계산값은 원래의 메시지에 대한 서명으로 인정됩니다. 해쉬값에 대한 서명이 원 메시지에 대한 서명으로 인정되기 위해서는 같은 해쉬값을 갖는 또다른 메시지를 찾아내기가 계산적으로 어려워야 합니다. 해킹을 당할 수 있기 때문입니다. 또한 해쉬 계산이 쉬워 풀어버린다면 그 해쉬함수는 사용할 수 없습니다.

 해쉬함수는 임의의 길이의 입력으로부터 짧은 길이의 해쉬값을 출력하므로, 입력은 서로 다르지만 같은 출력을 내는 충돌이 반드시 존재합니다. 만일 같은 해쉬값을 갖는 다른 메시지를 찾아내기가 쉽다면, 서명자는 자신의 서명을 다른 메시지에 대한 서명이라고 우길 수 있을 것입니다. 이렇게 되면 전자서명에 대한 신뢰가 불가능하고 전자거래에 사용할 수 없게 됩니다. 그러므로 안전한 해쉬함수로 사용될 수 있기 위해서는 충돌을 찾아내기 어렵다는 특성을 가져야 합니다.

23. 대칭키/비대칭키

->1. 대칭키(비밀키)는

- 암/복호화키가 동일

- 대표 암호알고리즘 : DES, 3DES, TDES, AES, SEED, ARIA 등

- 대체적으로 bit수가 작고 수행시간이 짧다.

- 사용에 제한적이다

- 사용 예 : 디스크 암호화

 

비대칭키(공개키,개인키)는

- 암/복호화키가 상이

- 대표 암호알고리즘 : RSA, ECC 등

- 대체적으로 bit수가 많고 수행시간이 길다.

- 공개라는 단어에 어울리게 범용적으로 사용 가능하다.

- 사용 예 : 비밀번호 암호화

- 공개키로 암호화한것을 개인키로 복호화한다.(암복호화시 동일키를 사용할 수 없다.)

 

25. html이란?

-> HTML이란 우리가 보는 웹 페이지의 대부분은 확장자가 html이다. htm인 것도 있는데, 그것은 예전 도스 기준으로 확장자가 3자밖에 되지 않기 때문에 어쩔 수 없이 끝을 자른 것으로 요즘은 잘 없다. 기타 php, aspx, jsp 등도 있다. 이들은 각각 웹 서버의 처리 엔진에 따른 결과물인데, 사실 확장자는 중요한 게 아니다. 어차피 확장자가 php,aspx,jsp인 것도 다들 html이다. 웹 브라우저는 확장자를 보고 이게 html인 줄 아는 게 아니라, 헤더에 있는 타입을 보고 아는 것이다. 우리가 보기에 확장자가 php라도, 헤더에는 txt/html로 타입이 규정되어 있고, 웹 브라우저는 그래서 이게 html인 줄 안다. 웹 페이지는 메모장으로 소스 보기를 하면 보이듯이 <tag>이런 태그로 둘러싸인 텍스트 문서이다. 그림 파일이나 다른 요소는 따로 표시되어 있지 페이지 속에 들어가지 않는다.

24. http와 https 차이

->HTTP란 HTML 같은 문서를 웹 브라우저가 웹 서버에 요청하는 프로토콜이다. 프로토콜이라는 것은 일종의 대화 규칙이다. 우리가 폰뱅킹할 때를 보면 지정된 코드를 누르면 정해진 응답이 온다. 그런 것이다. 이게 없다면 웹 서버는 웹 브라우저가 무슨 페이지를 달라고 하는 건지도 모를 것이고 웹 브라우저도 웹 서버가 무슨 페이지를 보내는 건지 알 수가 없다. Http도 그냥 텍스트 교환일 뿐이다. 복잡한 바이너리 데이터가 아니라 그냥 텍스트 메시지를 주고 받는다. 물론 그 텍스트 메시지 안에 HTML 페이지도 들어 있다. 텍스트이기 때문에 만약 내가 있는 네트워크 안에서 누가 그 신호를 가로채어 본다면 내용이 그대로 보이게 된다. 만약 내가 메일을 읽고 있는데 누가 그 신호를 가로챈다면 메일 내용을 읽을 수 있을 것이다.

HTTPS란 http하고 거의 같지만 모든 통신 내용을 암호화하는 것이 다르다. 사실 s가 secure socket, 즉 안전한 통신망을 뜻한다. 우리는 파일에 암호를 많이 걸어 봤다. 어떤 키를 설정해서 걸면 나중에 풀 때에도 그걸 입력해 푸는 것이다. 키라는 것은 암호화를 푸는 암호 즉 패스워드같은 것이다. 웹 서버가 키 하나를 정해서 페이지를 암호화해서 사용자의 웹 브라우저로 보내고 웹 브라우저는 그 키를 이용해서 페이지를 복원한다... 이러면 좋겠지만 이렇게 간단하지 않다. 웹 서버는 하나이지만 사용자는 불특정 다수이다. 그런데 키를 사용자들에게 줘 버리면 아무나 암호화를 풀 수 있게 된다. 영희에게 갈 페이지를 철수도 풀어서 볼 수 있게 되는데, 이러면 암호화의 효과가 없다.

 즉, 페이지 암호화 키가 그 페이지를 보는 특정 사용자에게만 알려져야 한다. 어떻게 이렇게 할 수 있을까? 이것이 바로 https 프로토콜이 하는 것이다. 위에서 말한 암호화 방식을 사용하되, 그 키를 다시 공개 키로 암호화하고 인증하는 것이다. 공개 키는 쉽게 말해서 데이터를 암호화하는데 키가 두 개 필요하다는 것이다. 암호화를 푸는 데에는 그 두 개 중 하나의 키만 있으면 된다. (수학적으로 로그 지수를 찾는 것이 어려운 문제에 기초하고 있다. 이렇게 자세한 것까지 알고 싶은 사람은 없겠지만.) 

이게 무슨 뜻일까? 

 옥션 사이트에서는 A,B라는 키를 가지고 있다. 그리고 이 B라는 키만 사용자들에게 알려 준다. 그리고 옥션 사이트에 웹 브라우저가 연결을 시도할 때, 파일 암호화 키를 이 A,B 키로 암호화해서 보내 준다. 그러면 사용자들은 B라는 키로 데이터를 풀어 볼 수 있다. A는 옥션 관리자 말고는 아무도 모르기 때문에, B만 알아서는 옥션과 똑같이 암호화를 할 수 없다. 즉 사용자는 B로 풀어 봐서 풀어지면 이 데이터는 A키를 아는 옥션 관리자가 암호화한 것이라는 걸 알 수 있는 것이다. http 프로토콜의 경우 중간에서 네트워크 데이터를 가로채어서 마치 자기가 옥션 사이트인 것처럼 해서 가짜 페이지를 보낼 수도 있다. 하지만 https의 경우에는 A키를 모르기 때문에 중간에서 누가 그렇게 할 수가 없다. 이렇게 해서 반대편이 옥션이라는 것을 우리는 믿을 수 있다. 이렇게 믿을 수 있으면 IE같은 브라우저에서는 주소 창의 색을 다르게 해서 안전하다고 알려 준다. 이렇게 해서 웹 서버와 사용자가 교환한 키로 전체 이후로는 HTML을 암호화해서 교환하는 것이다. 이렇게 되면 중간에서 웹 페이지를 누가 가로채어도 내용을 전혀 읽을 수 없다. 사실 시간이 주어진다면 암호화를 풀 수도 있다. 예를 들어 1024비트 암호화를 사용한다면 암호 키가 1024비트, 즉 2의 1024승이라는 것이다. 암호를 계산해서 푸는 방법은 없다 (있다면 그런 암호화는 폐기된다). 키를 모르고 암호화를 푼다는 것은 모든 키를 하나씩 다 대입해서 풀릴 때까지 해 보는 것이다. 그러면 위의 경우 평균적으로 2의 512승 번을 해 봐야 한다. 2의 512승과 2 x 512는 차원이 다르다. 2의 20승만 해도 백 만이 넘는다. 아무리 빠른 컴퓨터로 대입해도 아마 몇 천 년은 해야 할 것이다. 그래서 안전한 것이다.

25-2. 그럼 https 만 쓰나?

-> 그러면 https가 안전한데 다 https를 쓰지 http를 뭐하러 쓰느냐고 할 것이다. https 암호화를 하려면 웹 서버에 부하가 생기고, 위에서 말한 B가 그 서버의 인증서가 되는데, 이것은 Verisign 같은 업체에서 비싼 돈을 주고 사야하므로, 특히 우리 나라 웹 사이트들은 잘 쓰지 않는다. 하지만 외국 금융 사이트에서는 https는 필수이다. 또 http는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있지만 https의 경우에는 소켓 (데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 https 인증을 해야 한다. 그래서 시간이 또 걸린다.

26. get과 post 방식 차이?

-> GET은 주소줄에 값이 ?뒤에 쌍으로 이어붙고 POST는 숨겨져서(body안에) 보내진다. GET은 URL에 이어붙기 때문에 길이제한이 있어서 많은양의 데이터는 보내기 어렵고 POST는 많은 양의 보내기에도 적합하다.(역시 용량제한은 있지만)

즉 http://url/bbslist.html?id=5&pagenum=2 같이 하는 것이 GET방식이고 form을 이용해서 submit을 하는 형태가 POST입니다. 

 id를 넘겨서 게시판의 리스트를 가져온다고 하면 당연히 GET을 쓸 것이고 글을 작성한다고 하면 POST를 작성하는 것이 일반적입니다. 전달해야 될 양이 많을 경우에는 고민없이 POST를 쓰게 되지만 양이 많지 않은 경우에는 GET도 되고 POST도 되기 때문에 고민이 시작됩니다. GET을 써야하나 POST를 써야하나. GET을 쓰면 URL이 깔끔해 지는 효과도 있기 때문에 작은 양을 여러개 전달해야 할 경우에는 POST를 써야하는가 하는 고민을 하게됩니다.

 GET은 가져오는 것이고 POST는 수행하는 것입니다.

 이 개념만 잘 생각하고 있으면 상황에 따라서 어느정도 선택을 할 수 있습니다.(물론 그래도 좀 고민되는 예외상황들은 있게 마련이죠.) 좀 자세히 설명하면 GET은 Select적인 성향을 가지고 있습니다. GET은 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태등을 바꾸지 않습니다. 게시판의 리스트라던지 글보기 기능 같은 것이 이에 해당하죠.(방문자의 로그를 남긴다거나 글읽은 횟수를 올려준다거나 하는건 예외입니다.) 반면에 POST는 서버의 값이나 상태를 바꾸기 위해서 사용합니다. 글쓰기를 하면 글의 내용이 디비에 저장이 되고 수정을 하면 디비값이 수정이 되죠. 이럴 경우에 POST를 사용합니다.

  

27. 웹 작동 방식?

-> (1) 사용자의 웹 브라우저에서 http://서버주소/xxx.jsp 형태로 해당 페이지(jsp페이지)를 웹 서버로 요청한다.

(2) 웹 서버는 jsp에 대한 요청을 jsp컨테이너(웹 컨테이너)에 처리를 넘김

(3) jsp 파일이 처음 요청된 것이면 jsp파일을 서블릿(.java파일생성)으로 변화하는 파싱을 거친다.

     ※ 파싱 : 가공되지 않은 데이터에서 원하는 특정한 문자열을 빼내는 작업

     (이전에 요청했던 페이지면 파싱할 필요 없이 파싱했던 클래스파일을 메모리에 적재한다)

     jsp파일은 실행을 위해 서블릿으로 파싱되고, 클래스파일로 컴파일이 되는데 이런 과장은 jsp파일이 처음으로 호출되었을때만 거친다.

(4) 서블릿 파일은 자바에서 실행가능한 클래스파일로 컴파일 된다.

(5) 클래스 파일은 메모리에 적재가 되어 실행된다.

(6) 실행결과는 다시 웹서버에게 넘겨진다.

(7) 웹 서버는 웹브라우저가 인식할수 있는 html 형태로 결과를 응답한다. html 페이지를 브라우저에서 실행시켜 표시한다.

     (브라우저는 html태그로 구성된 페이지를 실행시켜 주는 프로그램으로, 웹서버에서 html이 실행되는것이 아니라 브라우저에서 실행되어 보여진다)

28. TCP/IP 란

->"TCP/IP는 패킷 통신 방식의 인터넷 프로토콜인 IP (인터넷 프로토콜)와 전송 조절 프로토콜인 TCP (전송 제어 프로토콜)로 이루어져 있다. IP는 패킷 전달 여부를 보증하지 않고, 패킷을 보낸 순서와 받는 순서가 다를 수 있다.(unreliable datagram service) TCP는 IP 위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다. HTTP, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 애플리케이션 프로토콜들이 IP 위에서 동작하기 때문에, 묶어서 TCP/IP로 부르기도 한다."

29. 접근 제어(CORS) HTTP 접근 제어 (CORS)

->  CORS는 웹 서버에게 보안 cross-domain 데이터 전송을 활성화하는 cross-domain 접근 제어권을 부여합니다. 모던 브라우저들은 cross-origin HTTP 요청의 위험성을 완화시키기 위해 (XMLHttpRequest와 같은) API 컨테이너 내에서 CORS를 사용합니다. Cross-Origin Resource Sharing 표준은 웹 브라우저가 사용하는 정보를 읽을 수 있도록 허가된 출처 집합를 서버에게 알려주도록 허용하는 HTTP 헤더를 추가함으로써 동작합니다. 추가적으로, 사용자 데이터 상에서 부수 효과를 일으킬 수 있는 HTTP 요청 메서드에 대해(특히, GET 이외의 HTTP 메서드들 혹은 어떤 MIME 타입을 사용하는 POST 사용에 대해), 스펙은 브라우저가 요청을 "preflight"(사전 전달)하도록 강제하는데, 이는 HTTP OPTIONS 요청 메서드를 이용해 서버로부터 지원 중인 메서드들을 내려 받은 뒤, 서버에서 "approval"(승인) 시에 실제 HTTP 요청 메서드를 이용해 실제 요청을 전송하는 것을 말합니다. 서버들은 또한 클라이언트에게 (Cookie와 HTTP Authentication 데이터를 포함하는) "credentials"가 요청과 함께 전송되어야 하는지를 알려줄 수도 있습니다.

30. Interpreter vs compiler 언어

-> 컴파일러와 인터프리터를 사용한 언어를 각각 컴파일 언어, 인터프리터 언어라고 불립니다. 둘 다 코드를 변환한다는 점은 동일하나 그 동작에 있어서 차이점이 있습니다.

 우선 컴파일러는 전체를 모두 변환하여 실행합니다. 하지만 인터프리터의 경우 한 줄 단위로 변환 및 실행을 반복합니다. 이는 마치 번역하는 것과 비슷합니다.

 무엇이 더 좋은 성능을 가져오는가는 상황에 따라 다릅니다. 컴파일러는 한번에 모두 읽고 실행하지만 처음 컴파일 과정이 매우 오래걸리고 메모리의 차지도 많습니다. 하지만 컴파일 이후 실행이 빠르고 더 이상 변환하지 않아 효율적입니다. 반면에 인터프리터는 처음에 빨리 실행되는 반면 많은 과정이 반복될 경우 계속해서 변환 과정을 거쳐야합니다.

 어떤 상황과 환경에서 컴파일러 또는 인터프리터를 사용하는게 효과적인지 판단하여 사용해야합니다. 둘 다 장단점을 가지고 있으며 두 가지 방식 모두 매우 편리한 방법으로 많이 사용되고 있습니다.

31. 블록체인 쉽게 설명?

-> 은행을 비롯한 금융기관들은 클라이언트들의 거래내용을 해당 은행에서 확인하고 기록한다. 그래서 거래를 할때 해당 금융기관에 대한 신뢰가 반드시 필요하다. 하지만 블록체인상에서의 장부 작성은 블록체인 네트워크에 참여하고 있는 사람들(이를 노드라고 한다)이 그 기록이 참인지 거짓인지 과반수의 동의를 얻어야 장부에 기록이 된다. 이 노드들은 전 세계적으로 분산되어있고 전세계를 아우르는 하나의 거대한 장부를 형성한다. 따라서 신뢰가 필요가 없이 합의를 통해서 기록이 작성된다. 이때 우리는 투표를 생각 할 수 있다. 현행 선거제도를 보면 한명의 사람이 하나의 투표권을 가져서 가장 많은 지지를 얻은 사람이 대표로 선출 되는 방식이다.

 그런데 블록 생성 합의과정은 하나의 노드가 하나의 투표권을 가지지 않는다. 가장 많고 가장 빨리 작업을 한 사람이 블록에 기록하고 블록을 생성할 수 있는 투표권을 더 많이 갖는다고 할 수 있다. 이것이 작업증명(proof of work)이라는 것인데 여기에서 작업이란 수학문제를 푸는 것을 말한다. 다시말해 가장 빠르고 많은 수학문제를 푸는 사람이 블록을 생성할 수 있는 권한을 더 많이 갖게된다. 그런데 이 수학문제는 사람의 머리로는 풀 수 없다. 고도의 연산능력을 갖춘 슈퍼컴퓨터가 계산할 수 있는 수학문제이다.

32. SSL

-> SSL(Secure Socket Layer) 프로토콜은 처음에 Netscape사에서 웹서버와 브라우저 사이의 보안을 위해 만들었다. SSL은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 아래는 SSL이 어떻게 작동하는지에 대한 간단한 과정을 설명한 것이다.

[웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)

[웹서버] Public Key를 인증서와 함께 전송한다.

[웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. (역주:Internet Explorer나 Netscape와 같은 웹브라우저에는 이미 Verisign, Thawte와 같은 널리 알려진 root CA의 인증서가 설치되어 있다) 또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인한다.

[웹브라우저] Public Key를 사용해서 랜덤 대칭 암호화키(Random symmetric encryption key)를 비릇한 URL, http 데이터들을 암호화해서 전송한다.

[웹서버] Private Key를 이용해서 랜덤 대칭 암호화키와 URL, http 데이터를 복호화한다.

[웹서버] 요청받은 URL에 대한 응답을 웹브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저로 전송한다.

[웹브라우저] 대칭 키를 이용해서 http 데이터와 html문서를 복호화하고, 화면에 정보를 뿌려준다.