SSH 내부는 어떻게 소통하고 있는가?

1.  대칭키를 공유하기까지

1-1. 클라이언트에서 서버로 connection 맺는다. ssh 버전확인등 

1-2. 이제부터 바이너리 패킷으로 통신한다.

1-3. 서버는 id 를 클라이언트에 노출한다. 이 id 는 서버의 rsa public 키 이다.

1-4. 클라이언트가 처음 서버와 접속하는것이라면 저 서버키1에 대한 경고가 클라이언트에 뜬다.

1-5. 서버에 의해 서버키2가 클라이언트에 제공된다. 이 서버키2 는 ssh2 에서는 사용되지 않는다. 

       이 키는 서버의 매시간마다 디폴트 설정에 따라 생성된다. 

1-6. 서버는 8 랜덤바이트 체크바이트를 만든다. 

1-7. 서버는 지원하는 암호화관련 방법들을 제공한다. 

1-8. 클라이언트는 저 방법중에 하나를 택해서 대칭키를 만든후에 서버로 보낸다. 이때 대칭키를 위의 서          버키1,2로 이중 암호화한다.

1-9. 서버는 해당 암호화된 대칭키를 받아서 복호화 한다.

1-10. 최종적으로 그 대칭키를 이용하여 앞으로 클라이언트와 서버사이 통신의  암호화에 사용한다.

2. 클라이언트 인증

2-1. 비밀번호를 통한 인증

 * 비번을 대칭키를 이용하여 암호화하여 서버로 보내서 클라이언트를 인증한다. 

 * 그 후로는 대칭키로 통신한다. 

2-2. public key 를 통한 인증 

 준비)

 * 클라이언트는 public key 와 개인키를 만든다. 

 * 클라이언트의 public key 를 서버에게 준다.

인증) 

 * 이후에 로그인을 할때  서버에 존재하는 클라이언트의  public key 로 랜덤 256bit 스트링를 암호화하여    클라이언트에게 준다. 

 * 클라이언트는 그것을 받아서 자신의 개인키로 복호화한다. 그 후 256bit 스트링을 대칭키와 합쳐서 md5    hash 값으로 만든다. 

 * 그 해쉬값을 서버로 보내고, 그 해쉬값을 서버에서 검증하여 일치하면 클라이언트 인증이 된것이다. 

 * 그 후에는 대칭키로 통신한다.  

http://iloveulhj.github.io/posts/http/http-digest-auth.html 펌

Feb 15, 2015

이 포스트는 “HTTP 완벽가이드”의 “13장, 다이제스트 인증”을 정리한 내용입니다.

---

• 기본 인증은 편리하고 유연하지만 안전하지 못함
• 다이제스트 인증은 기본 인증과 호환되는 대체재로서 개발
• 널리 쓰이지는 않지만 개념은 보안트랜잭션의 구현에 유용함

---

다이제스트 인증의 개선점

특징

• 비밀번호를 네트워크를 통해 평문으로 전송하지 않음
• 인증 체결을 가로채서 재현하지 못함
• 구현 방법에 따라 메시지 내용 위조 방지 가능

단방향 다이제스트

• 다이제스트(요약)는 단방향 함수로 동작, 무한 가지의 모든 입력값을 유한의 범위로 압축 변환
• MD5(메시지 다이제스트 #5), SHA(Secure Hash Algorithm)…
• 요약함수는 보통 cryptographic checksums로 불림, 단반향 해시 함수이거나 fingerprint function임

재전송 방지를 위한 난스 사용

• 난스(nonce)라 불리는 자주 바뀌는 증표를 발급
• 다이제스트를 탈취하여 서버로 전송하는 해킹을 막기위한 방법
• 다이제스트는 특정 난스 값에 대해서만 유효

다이제스트 인증 핸드쉐이크

그림1. 다이제스트 인증 핸드셰이크
자료 출처: David Gourley and Brian Totty, "HTTP: The Definitive Guide (Definitive Guides)", O'Reilly, 2002

1. 서버는 난스값을 계산
2. 난스를 WWW-Authenticate 인증요구 메시지에 담아, 서버가 지원하는 알고리즘 목록과 함께 클라이언트에 전송
3. 클라이언트는 알고리즘 선택, 비밀번호와 그 외 데이터에 대한 요약 계산
4. 클라이언트는 Authorization 메시지에 요약을 담아 서버로 전송, 서버를 인증하려면 클라이언트를 난수를 보낼 수 있음
5. 서버는 요약, 알고리즘, 그외 보조데이터를 받아 요약을 검증함. 클라이언트가 서버에게 인증을 요구했다면 클라이언트 요약이 만들어 클라이언트에 전송. 다음번 난스를 클라이언트에게 미리 전송하기도 함

---

요약(digest) 계산

다이제스트 인증이 핵심은 공개된 정보, 비밀 정보, 시한부 난스 값을 조합한 단방한 요약

다이제스트 알고리즘의 입력 값

H(d)	단방향 해시함수
KD(s,d)	요약함수. s는 secret, d는 data를 의미
A1	비밀번호 등 보안 정보를 담고 있는 데이터 덩어리
A2	요청 메시지의 비밀이 아닌 속성을 담고 있는 데이터 덩어리

H(d)와 KD(s,d) 알고리즘

• RFC2617에서 제안된 알고리즘은 MD5, MD5-sess(‘sess’는 세션을 의미)
• 만약 알고리즘이 정해지지 않았다면 MD5가 기본

• KD 요약 함수는 콜론으로 연결된 비밀 데이터와 일반데이터의 MD5를 계산

  H(<데이터>) = MD5(<데이터>)  
  KD(<비밀>,<데이터>) = H(연결(<비밀>:<데이터>)
  

보안 관련 데이터(A1)

• 사용자 이름, 비밀번호, 보호 영역, 난스와 같은 비밀 보호 정보로 이루어짐

  MD5: A1 = <사용자>:<영역>:<비밀번호>
  MD5-sess: A1 = MD5(<사용자>:<영역>:<비밀번호>):<난스>:<c난스>
  

메시지 관련 데이터(A2)

• URL, 요청 메서드, 메시지 엔티티 본문과 같은 메시지 자체의 정보

• qop(quality of protection)에 따라 A2의 두가지 사용법이 있음

  정의되지 않음:  <요청메서드>:<uri 지시자 값>
  auth:  <요청메서드>:<uri 지시자 값>
  auth-int:  <요청메서드>:<uri 지시자 값>
  

---

보호수준(qop) 향상

• qop 필드는 WWW-Authenticate, Authorization, Authentication-Info에 모두 존재 가능
• qop 필드는 클라이언트와 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할 수 있지 협상할 수 있게 허용

메시지 무결성 보호

• qop=”auth-int”면 메시지 무결성 보호가 적용
• auth-int의 경우 계산되는 H(엔티티 본문)은 메시지 본문의 해시가 아닌 엔티티 본문의 해시

---

실제 상황에 대한 고려

다중 인증 요구

• 서버는 클라이언트에게 가능한 가능한 인증 요구를 보냄

오류 처리

• 다이제스트 인증에서, 지시자나 그 값이 적절하지 않거나 요구된 지시자가 빠진 경우 400 Bad Request가 절절한 응답임
• 인증서버는 반드시 uri 지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같음을 확인해야함
  다를 경우 이는 공격의 징후일 수 있으므로 로그를 남기는 것이 좋음

---

보안에 대한 고려사항

• 헤더 부당 변경
• 재전송 공격
• 다중 인증 메커니즘
• 사전(dictionary) 공격
• 악의적인 프락시와 중간자 공격
• 선택 평문 공격
• 비밀번호 저장

---

다이제스트 인증 기능의 구현을 위한 지원 데이터

WWW-Authenticate 지시자들

realm	사용자 이름과 비밀번호가 어디 사용될 것인지 알려주기 위해 사용자에게 보여질 문자열
nonce	401 응답이 만들어질 때마다 유일하게 생성되어야 하는 서버에 특화된 데이터 문자열
domain	보호될 공간을 정의한 따옴표로 감싸진 URI들의 공백으로 분리된 목록
opaque	서버에 의해 정의된 데이터의 문자열, 클라이언트는 같은 보호 공간의 URI에 대한 다음번 요청에서 Authorizaiton 허더에 이 값을 담아 반환
stable	클라이언트로부터의 이전 요청이 nonce 값이 신선하지 않아서 거부되었음을 의미하는 플래그
algorithm	다이제스트와 체크섬을 생성할 때 사용하는 알고리즘, 기본 값은 MD5
qop	선택적, 서버가 지원하는 보호 수준을 의미

Authorization 지시자들

username	특정 realm에서의 사용자 이름
realm	WWW-Authenticte 헤더에 담겨 클라이언트에게 넘겨진 releam
nonce	WWW- Authenticate 헤더에 담겨 클라이언트에게 넘겨진 nonce
uri	요청 URI에서의 URI, 프락시에 의해 요청이 변경될 수 있기 때문에 존재
response	다이제스트 값, 사용자가 비밀번호를 알고 있음을 증명
algorithm	다이제스트와 체크섬을 생성할 때 사용하는 알고리즘, 기본 값은 MD5
opaque	서버에 의해 정의된 데이터의 문자열, 같은 보호 공간의 URI에 대한 다음번 요청에서 값을 그대로 넣어서 반환
cnonce	qop 지시자가 보내진 경우만 포함. 메시지 무결성 보호를 제공
qop	클라이언트가 메세지에 적용한 “보호 수준”의 정도
nc	qop 지시자가 보낸 경우에만 포함. 클라이언트가 이 요청의 nonce값과 함께 보낸 요청들의 횟수 합계

Authentication-Info 지시자들

nextnonce	미래의 인증 응답 시에 클라이언트가 사용해주기를 서버가 원하는 nonce
qop	서버에 의해 응답에 적용된 ‘보호 수준”의 정도
rspauth	response auth를 의미. 선택적인 응답 다이제스트가 들어있으며 이를 이용해 상호 인증을 지원
cnonce	응답 대상인 클라이언트의 요청에 들어있는 값과 반드시 같아야 함
nc	응답 대상인 클라이언트 요청에 들어있는 값과 반드시 같아야 함

추가 정보

RFC 2617,”HTTP Authentication: Basic and Digest Access Authentication”

---

출처: "HTTP 완벽가이드", 이응준, 정상일 옮김, 인사이트, 2014

http://hyeonstorage.tistory.com/125 펌

웹에서 세션(session)의 사용

1. 세션(session)의 개요

쿠키가 웹 브라우저에 사용자의 상태를 유지하기 위한 정보를 저장했다면, 세션(session)은 웹 서버 쪽의 웹 컨테이너에 상태를 유지하기 위한 정보를 저장한다.

세션은 사용자의 정보를 유지하기 위해 javax.servlet.http 패키지의 HttpSession 인터페이스를 구현해서 사용한다. 쿠키는 사용자의 상태 유지를 위한 정보를 웹 브라우저에 저장해서 웹 서버가 쿠키 정보를 읽어서 사용한다.

이것은 웹 브라우저에 저장된 쿠키는 웹 서버에서 열어볼 수 있다는 점에서 보안상 문제가 발생할 수 있다.

따라서 사용자의 정보를 유지하기 위해서는 쿠키를 사용하는 것보다 세션을 사용한 웹 브라우저와 웹 서버의 상태 유지가 훨씬 안정적이고, 보안상의 문제도 해결할 수 있다.

세션은 웹 브라우저 당 1개씩 생성되어 웹 컨테이너에 저장된다.

웹 서버는 각각의 웹 브라우저로부터 발생한 요청에 대해서 특별한 식별자를 부여한다. 이후에 이 식별자를 웹 브라우저에서 발생한 요청들과 비교해서 같은 식별인지를 구별하게 된다. 이 특별한 식별자에 특정한 값을 넣을 수 있으며, 이것을 사용해서 세션을 유지하게 된다.

2. 세션(Session) 메소드 리스트

3. 세션(Session)의 속성

- 세션의 속성 설정은 session 객체의 setAttribute() 메소드를 사용한다.

session.setAttribute("id", "value");

이때 주의할 사항은 세션의 속성 값은 객체 형태만 올 수 있다는 것이다.

session 객체는 웹 브라우저와 매핑되므로 해당 웹 브라우저를 닫지 않는 한 같은 창에서 열려진 페이지는 모두 같은 session 객체를 공유하게 된다. 따라서 session 객체의 setAttribute() 메소드를 사용해서 세션의 속성을 지정하게 되면 계속 상태를 유지하는 기능을 사용할 수 있게 된다.

- 세션의 속성을 사용하려면 session 객체의 getAttribute() 메소드를 사용한다.

String id = (String)session.getAttribute("id");

getAttribute() 메소드는 리턴 타입이 Object 타입이므로 사용 시 실제 할당된 객체 타입으로 형변환(casting)을 해야 한다.

- 세션의 속성을 삭제하려면 session 객체의 removeAttribute() 메소드를 사용한다.

session.removeAttribute("id");

- 세션의 모든 속성을 삭제할 때는 session 객체의 invalidate() 메소드를 사용한다.

session.invalidate();

4. 세션(Session) 사용 예제

- 세션(Session) 설정 (로그인 성공시에 로그인 아이디를 세션에 저장한다.)

<%@ page language ="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%>

<% request.setCharacterEncoding("euc-kr");%>

<%

String id = request.getParameter("id");                        // request에서 id 파라미터를 가져온다

String passwd = request.getparameter("passwd");      // request에서 passwd 파라미터를 가져온다.

--- 로그인 처리 ...   로그인 성공시 check 는 TRUE --

if(check){                                                        // 로그인 성공시

session.setAttribute("id", id);                 // 세션에 "id" 이름으로 id 등록

response.sendRedirect("main.jsp");               // 로그인 성공 메인페이지 이동

}else{%>                                                        // 로그인 실패

<script>

alert("로그인 실패");

history.go(-1);                                    // 이전 페이지로 이동

</script>

<%}%>

- 세션(Session) 가져오기 (세션에서 아이디를 가져와 로그인 상태를 인증하고, 값이 없을 경우 로그인 페이지로 넘긴다.)

<%@ page language ="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%>

<% request.setCharacterEncoding("euc-kr");%>

<%

String id = "";

try{

id = (String)session.getAttribute("id");            // request에서 id 파라미터를 가져온다

if(id==null||id.equals(""){                            // id가 Null 이거나 없을 경우

response.sendRedirect("loginform.jsp");    // 로그인 페이지로 리다이렉트 한다.

}

<%}%>

- 세션(Session) 제거하기 (로그아웃 시 현재의 세션 정보를 제거한다.)

<%@ page language ="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%>

<% session.invalidate(); %>                         // 세션 정보 제거

<script>

alert("로그아웃 되었습니다.");

location.href="logout.jsp";                                    // 로그아웃 페이지로 이동

</script>

HTTPS와 SSL 인증서

톰캣 HTTPS 설정 과  사설인증서 획득법

SSL 인증서를 무료로 

openssl 인증서 생성 절차

0. 인증 / 인가 / 무결성 이란 ? 

인증 (Authentication)  :  A 라는 사람이  그 싸이트 혹은 그 서비스를 사용할수있는가?  신원 확보 목적.
인가 (Authorization)    :  A 라는 사람이 서비스에서 어떤것을 할수있도록 하는가 ? ( 파일 리딩만 하게하자) 

무결성                  :   A -> B 로 어떤 메세지를 보냈을때 그 메세지가 바뀌거나 깨지지 않음을 보장하는것.

1. 암호화 / 복호화 란 ? 

암호화 :  어떤 문자열 "hello world"  를  "332XF3FX_*)3" 로 바꾸는것.

복호화 :   "332XF3FX_*)3"  을 다시  "hello world" 로 환원하는것.

암호화 알고리즘에는 DES , AES 등이 있다. 

JAVA AEC :  http://andang72.blogspot.kr/2012/02/aes.html

암호화와 복호화를 위해서는 key  (비밀키) 라는것이 필요하다. 

2. 대칭형 암호화 

A 와 B  라는 각각의 Peer 를 상상해보자. 

각각의 컴퓨터에 동일한 key 를 복사해두고, 동일한 key 를 이용해서 암호화 / 복호화를 하는것이 

대칭형 암호화이다. A,B 모두를 제어권에 두고있다면 대칭형 암호화로 충분하다.

하지만  A 는 내가 관리하는데 B 를 관리할수없을경우  B 에게 나의 비밀키를 보내야하는데

그 중간에서 탈취를 당하면 탈취한사람은 A 와 B 의 비밀 이야기를 엿들을수있게 된다.

3. 공개키 암호화 ( 비대칭형 ) 

공개키 암호화 (비대칭형) 방법이 대칭형과 다른것은 키를 2개 만드는것이다.

비밀키 1개에서 ->   공개키,개인키 요렇게 2개!!

개인키는 자신이 가지고 있고, 공개키를 B 에게 전달한다. 전달받은 B 는 자신의 공개키를 A에게 보낸다.

공개키로 암호화하고 개인키로 복호화한다. 암호화는 누구나 할수있지만 , 복호화는 자신밖에 못하기때문에

보안을 이룰수있다.

4. 비대칭형 / 대칭형 믹스 

위의 공개키암호화는 상당히 안전하지만 , 공개키/개인키를 통한 암호화/복호화는 상당히 느리다.

따라서 처음에만 공개키로 하고 다음부터는 대칭키로 암호화/복호화를 하는 전략을 쓴다.

1 .A 는 자신의 공개키를 B에게 전달한다. 

2. B 는 A의 공개키로 자신의 비밀키를 암호화해서 A에게 전달한다.

3. A 는 자신의 개인키로 B 의 비밀키를 복호화한다.

4. 공유된 B 의 비밀키로 통신한다.

이 방법은 B 가 A 의 공개키를 어떻게 진짜 A 의 공개키인지 믿을수 있나? 라는 화두를 던진다.

5. 해쉬 함수 

"EWEFWFWEEFWFWEWFWE32R2FF2F" 이렇게 긴 문장을 

"F3F34"  요렇게 짧게 바꾸는 작업을 말한다. 

해쉬된 문장을 원래 문장으로 바꾸는건 불가능하다.

해쉬를 왜 하냐면 , 짧으면 무엇이 좋을까?  

1. 암호화, 복호화 할때 시간이 단축된다.

2. 원래 문장을 전송에 사용할 필요가 없어진다. 따라서 비밀번호같은것의 노출을 피할수있다.

   예를들어 비밀번호를 해쉬함수를 통해서 걸러진 문장을 DB 에 저장해두면,  진짜 비밀번호를 알수는

   없지만, 동일한 비밀번호로부터 나온 결과라는것은 알수있게된다.

MD5 / SHA1 같은것을 사용한다.

6. 전자 서명 

상대방의 신원을 확인하기 어려운 사이버 공간에서 서로를 알아볼 수 있도록 한 쌍의 전자서명키 (공개키+개인키)를 사용하여 자신을 증명하는 것이 전자서명의 원리입니다. 공인인증기관으로부터 인증서를 발급받아 전자계약서 등에 전자서명을 하여 계약내용을 증명합니다.단지 사이버 공간이라는 환경과 모든 처리가 전자적으로 처리된다는 것이 차이점입니다.

네이버어플리케이션 전자서명의 원리 : http://helloworld.naver.com/helloworld/textyle/744920

7. 인증서 

당신과 접속해있는 사람이나 웹 사이트가 믿을 수 있는지 어떻게 판단할 수 있을까? 한 웹사이트 관리자가 있다고 가정하자. 그 사람이 당신에게 이 사이트가 믿을만하다고 (심각할 정도로) 열심히 설명했다. 당신이 그 사이트의 인증서를 설치해 주기를 바라면서 말이다. 한두번도 아니고 매번 이렇게 해야한다면 귀찮지 않겠는가?

인증서는 여러 부분으로 이루어져있다. 아래는 인증서 속에 들어있는 정보의 종류를 나타낸 것이다.

인증서 소유자의 e-mail 주소

소유자의 이름

인증서의 용도

인증서 유효기간

발행 장소

Distinguished Name (DN)

- Common Name (CN)

- 인증서 정보에 대해 서명한 사람의 디지털 ID

Public Key

해쉬(Hash)

SSL의 기본 구조는 당신이 인증서를 서명한 사람을 신뢰한다면, 서명된 인증서도 신뢰할 수 있다는 것이다. 이것은 마치 트리(Tree)와 같은 구조를 이루면서 인증서끼리 서명하게 된다. 그러면 최상위 인증서는? 이 인증서를 발행한 기관을 Root Certification Authority(줄여서 Root CA)라고 부르며, 유명한 인증 기관(역주:Verisign, Thawte, Entrust, etc)의 Root CA 인증서는 웹브라우저에 기본적으로 설치되어 있다. 이러한 인증 기관은 자신들이 서명한 인증서들을 관리할 뿐만 아니라 철회 인증서(Revoked Certificate)들도 관리하고 있다. 그러면 Root CA의 인증서는 누가 서명을 했을까? 모든 Root CA 인증서는 자체 서명(Self Signed)되어 있다.

8. SSL

SSL 은 위의 4번과 동일하다. 다만 추가된것은 공개키를 인증해주는 과정이 추가되었다.

A의 공개키를 CA 기관에 전자서명을 받아서 인증서를 받은후에 (CA 에서는 자신의 개인키로 암호화함) B에게 보내준다. B는 자신의 컴퓨터에 미리 존재하는 (브라우저안에도 있음) CA의 

공개키로 인증서를 확인하여,  A의 공개키를 얻는다.

HTTPS 에 사용된다.

9. JCA  

가)    전자 서명과 메시지 다이제스트 같은 기능에 대한 일반적인 API 제공

나)    주요 클래스들

①     MessageDigest

②     Signature

③     KeyPaireGenerator

④     KeyFactory

⑤     CertificateFactory

⑥     KeyStore

⑦     AlgorithmParameters

⑧     AlgorithmParameterGenerator

⑨     SecureRandom

다)    암호 서비스 제공자 Sun Provider(Java 2 기준, sun.security.provider.Sun)

①     MD5 메시지 다이제스트

②     SHA-1 메시지 다이제스트

③     DSA 전자 서명 사인과 검증

④     DSA 키 쌍 생성

⑤     DSA 키 변환

⑥     X.509 인증서 생성

⑦     Proprietary keystore 구현

⑧     DSA 알고리즘 매개변수

⑨     DSA 알고리즘 매개변수 생성

라)    암호 서비스 제공자 RSAJAC provider(com.sun.rsajca.Provider)

①     RSA 키 쌍 생성

②     RSA 키 변환

10) JCE

가)    주요 클래스와 인터페이스

①     Cipher

②     KeyAgreement

③     KeyGenerator

④     Mac

⑤     SecretKey

⑥     SecretKeyFactory

나)    JCE 접근 

KeyGenerator keyGenerator = KeyGenerator.getInstance(“Blowfish”);

Key key = keyGenerator.generatorKey();

Cipher cipher = Cipher.getInstance(“Blowfish/ECB/PKCS5Padding”);

cipher.init(Cipher.ENCRYPT_MODE, key);

byte[] cipherText = cipher.doFinal(myData);

다)    JCE 설치

이름

BouncyCastle

URL

http://www.bouncycastle.org

12. JSSE

13. JAAS

http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html

14. Java SASL

https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html

15. Java GSS-API

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/index.html

16. 커버로스 

http://publib.boulder.ibm.com/html/as400/v5r1/ic2986/info/rzakh/rzakha06.htm

17. LDAP 

http://jabcholove.tistory.com/89

18. 스프링에서의 보안

http://www.slideshare.net/madvirus/ss-36809454

19. AngularJS  에서의 보안 

https://www.youtube.com/watch?v=18ifoT-Id54

20. 하둡에서의 보안 

http://www.slideshare.net/oom65/hadoop-security-architecture