NETWORK SECURITY

네트워크 보안 에센셜

ESSENTIALS

4th EDITION

5.1 웹 보안의 필요성

5.2 안전 소켓 계층과 전송 계층 보안

5.3 전송 계층 보안

5.4 HTTPS

5.5 SSH

제5장 전송-레벨 보안

5.1 웹 보안의 필요성

• 웹 서버 침해 – 인터넷을 통한 웹 서버 공격에 취약

– 기업신뢰도 추락

– 경제적인 손실

• 시스템 – 다양한 소프트웨어로 구성되어 복잡

– 다양한 보안 공격에 취약

• 네트워크를 통한 침해확대

• 웹 보안에 대한 일반인의 무지 3

웹 보안 위협

• 소극적 공격

– 네트워크 트래픽 도청

– 제한된 웹 사이트 정보에 접근 허락받기

• 적극적 공격

– 다른 사용자로 위장

– 전송 메시지 변경

– 웹 사이트 정보 수정

4

장소에 따른 웹 보안 위협

• 웹 서버

• 웹 브라우저

• 브라우저와 서버 간의 네트워크 트래픽

5

웹 트래픽 보안 방법

• 웹이 제공하는 서비스 유형과 유사

• 웹이 사용하는 메커니즘과도 유사

• 웹 응용 범위나 TCP/IP 계층상 웹의 상대적 위치에 따라 달라짐 – 네트워크 층

• IP/IPSec

– 전송 층 • SSL/TLS

– 응용 층 • Kerberos, S/MIME

6

TCP/IP 에서 보안 기능의 위치

7

5.2 안전소켓계층과 전송계층 보안

• SSL

– 넷스케이프에서 최초로 작성

– 현재는 TLS로 전환

– SSLv3.1 이 TLS이다

– SSLv3와 호환 가능

8

SSL 구조

• 두 계층의 프로토콜로 구성

• SSL 프로토콜 스택

9

SSL 구성

• 핸드셰이크 프로토콜

– 핸드셰이크(Handshake) 프로토콜

– 경고(Alert) 프로토콜

– 암호명세변경(Change Cipher Spec) 프로토콜

• SSL 레코드 프로토콜

※ 설명은 역 순으로 하도록 한다. ※ 핸드셰이크 프로토콜 안에 동일한 이름의 핸드셰이크 프로토콜이 있음에 주의

10

SSL 개념

• 연결(Connection): – 적절한 서비스를 제공하는 전송(OSI 계층 모델의 – 정의) – 대등-대-대등 관계 – 일시적 – 한 개의 세션과 연관

• 세션(Session): – 한 클라이언트와 한 서버 사이의 연관 – 세션 시작은 핸드셰이크 프로토콜을 이용 – 세션 시 암호적 보안 매개변수 정의 – 매 연결시 보안매개변수 협상을 새로 하지 않기 위해

세션을 사용

11

세션상태(session state) 매개변수

• 세션 식별자(Session identifier):.

• 대등 인증서(Peer Certificate):

• 압축 방법(Compression method):

• 암호명세(Cipher spec):

• 마스터 비밀(Master secret):

• 재시작 여부(Is resumable):

12

연결 상태(connection state) 매개변수

• 서버와 클라이언트 랜덤(server and client random):

• 서버 기록 MAC 비밀(Server write MAC secret):

• 클라이언트 기록 MAC 비밀(Client write MAC secret):

• 서버 기록 키(Server write key): • 클라이언트 기록 키(Client write key): • 초기화 벡터(Initialization vectors): • 순서 번호(Sequence numbers):

13

SSL 레코드 프로토콜

• SSL 연결을 위한 2가지 서비스

– 기밀성(Confidentiality):

• SSL 페이로드 암호화에 쓸 공유 비밀키 정의

– 메시지 무결성(Message Integrity):

• 메시지 인증 코드(MAC) 생성에 사용할 공유 비밀키 정의

14

SSL 레코드 프로토콜 동작

1. 단편화(fragmentation)

2. 압축(compression)

3. 메시지 인증 코드(message authentication code)계산

4. 대칭 암호로 암호화(encrypted)

5. 헤더 붙이기(header attachment)

15

SSL 레코드 프로토콜 동작

16

단편화와 압축

• 단편화

– 214바이트보다 작거나 같은 크기 블록으로 단편화

• 압축

– 알고리즘을 자유롭게 선택

– 1024바이트 이하로

17

메시지 인증 코드

• 압축된 데이터의 메시지 인증 코드 계산

• 공유 비밀키 사용

• 계산방법 hash(MAC_write_secret || pad_2 ||

hash(MAC_write_secret || pad_1 || seq_num ||

SSLCompressed.type || SSLCompressed.length ||

SSLCompressed.fragment))

18

기호 설명

• || = 이어 붙여쓰기(concatenation) • MAC_write_secret = 공유 비밀키 • hash = 암호적 해시 알고리즘, MD5나 SHA-1 • pad_1 = MD5에서는 48번 반복하고, SHA-1에서는 40번(320

비트) 반복하는 바이트 0x36(0011 0110) • pad_2 = MD5에서는 48번 반복하고, SHA-1에서는 40번 반복

하는 바이트 0x5C(0101 1100) • seq_num = 이 메시지의 순서번호 • SSLCompressed.type = 이 단편 처리에 사용되는 상위-계층

프로토콜 • SSLCompressed.length = 압축된 단편의 길이 • SSLCompressed.fragment = 압축된 단편(만일 압축을 안 했

으면, 평문 단편)

19

대칭 암호로 암호화

• 압축된 메시지와 MAC을 대칭 암호로 암호화(encrypted)

• 암호화 시 내용의 길이가 절대로 1024바이트 이상 늘어나서는 안됨

• 총 길이가 214 + 2048 바이트를 초과하지 않도록 함

20

사용하는 암호화 알고리즘

21

헤더 붙이기

• 헤더 구성

– 콘텐츠 유형(Contents Type)(8 비트):

– 주 버전(Major Version)(8 비트):

– 부 버전(Minor Version)(8 비트):

– 압축된 길이(Compressed Length)(16 비트):

22

SSL 레코드 형식

23

핸드셰이크 프로토콜

• 암호명세 변경 프로토콜(Change Cipher Spec Protocol)

• 경고 프로토콜(Alert Protocol)

• 핸드셰이크 프로토콜(Handshake Protocol)

24

암호명세 변경 프로토콜

• 3가지 SSL-지정 프로토콜 중 가장 간단

• 한 바이트로 구성되고 값 1을 갖는 한 개의 메시지(그림 5.5(a) 참조)로 구성

• 목적: 계류상태를 현재 상태에 복사

– 연결에 사용할 암호도구(cipher suites)갱신

25

SSL 레코드 프로토콜 페이로드

26

경고 프로토콜

• 대등 개체에게 SSL-관련

• 각 메시지는 2바이트로 구성(그림 5.5(b) 참조) – 첫 번째 바이트는 메시지 엄밀성 전달을 위해

2가지 값을 갖는다 • 경고(warning)(1)

• 심각(fatal)(2) – SSL은 즉시 연결을 단절

– 두 번째 바이트에는 특정 경고를 나타내는 코드 포함

27

항상 심각(always fatal) 경고

• unexpected_message: – 적합하지 않은 메시지 수신

• bad_record_mac: – 부정확한 MAC 수신

• decompressed_failure: – 압축풀기 함수에 적합하지 않은 입력

• handshake_failure: – 보안 매개변수의 집합을 송신자가 협상할 수 없음

• illegal_parameter: – 핸드셰이크 메시지 안의 한 필드가 범위 밖에 있거나

다른 필드와 모순

28

기타 경고

• close_notify:

• no_certificate:

• bad_certificate:

• unsupported_certificate:

• certificate_revoked:

• certificate_expired:

• certificate_unknown:

29

핸드셰이크 프로토콜

•

30

SSL 핸드셰이크 프로토콜 메시지 유형

31

핸드셰이크 프로토콜 동작

32

핸드셰이크 프로토콜 동작

33

초기교환 4단계

• 보안 기능 설정

• 서버 인증과 키교환

• 클라이언트 인증과 키교환

• 종료

34

암호 계산

• 마스터 비밀 생성

• 마스터 비밀로 암호 매개변수 생성

35

마스터 비밀 생성

• 일회용 48-바이트

• 두 단계 생성

– pre_master_secret 교환

• RSA:

• Diffie-Hellman:

– 양쪽이 master_secret을 계산

36

master_secret 계산

master_secret = MD5(pre_master_secret || SHA('A' ||

pre_master_secret || ServerHello.random ||

ClientHello.random)) ||

MD5(pre_master_secret || SHA('BB' ||

pre_master_secret || ServerHello.random ||

ClientHello.random)) ||

MD5(pre_master_secret || SHA('CCC' ||

pre_master_secret || ServerHello.random ||

ClientHello.random))

37

암호 매개변수 생성

• 마스터 비밀로부터 다음을 생성

– client write MAC secret

– server write MAC secret

– client write key

– server write key

– client write IV

– server write IV

38

마스터 비밀에서 키 생성

key_block = MD5(master_secret || SHA('A' || master_secret ||

ServerHello.random || ClientHello.random)) ||

MD5(master_secret || SHA('BB' || master_secret ||

ServerHello.random || ClientHello.random)) ||

MD5(master_secret || SHA('CCC' || master_secret ||

ServerHello.random || ClientHello.random)) || . . .

39

5.3 전송 계층 보안

• TLS는 SSL을 인터넷 표준버전이 되도록 만든 IETF 표준

• TLS는 RFC 2246로 제안된 인터넷 표준(Proposed Internet Standard)으로 정의

40

버전 번호

• TLS 레코드 형식(TLS Record Format)은 SSL 레코드 형식(SSL Record Format)과 동일(그림 5.4 참조)

• 헤더의 필드도 동일

• 버전 값은 다름

• 현재 사용되는 TLS 버전 번호는 3.1

41

메시지 인증 코드

•

42

기호 설명

• H =내장된 해시 함수(TLS에 대해서 MD5 혹은 SHA-1)

• M = HMAC의 입력 메시지 • K+ = 왼쪽에 0들을 패딩해서 해시코드의 블

록 길이와 동일한 크기로 만든 비밀키(MD5와 SHA-1의 블록 길이는 512 비트)

• ipad = 00110110(16진수로 36)를 64 번 반복(512 비트)

• opad = 01011100(16진수로 5C)를 64 번 반복(512 비트)

43

MAC 계산

HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type ||

TLSCompressed.version || TLSCompressed.lelngth ||

TLSCompressed.fragment))

44

의사랜덤 함수

P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) ||

HMAC_hash(secret, A(2) || seed) ||

HMAC_hash(secret, A(3) || seed) || ...

• 여기서 A( )는 다음과 같이 정의 A(0) = seed

A(𝑖) = HMAC_hash(secret, A(𝑖 − 1))

45

TLS 함수 p_hash(secret, seed)

46

PRF 정의

PRF(secret, label, seed) = P_hash(S1, label || seed)

47

경고 코드

• TLS는 SSLv3에 정의된 모든 경고 코드를 지원 – no_certificate만 제외

• 심각으로 처리되는 경고

record_overflow: unknown_ca: access_denied: decode_error: protocol_version: insufficient_security:

unsupported_extension: internal_error: decrypt_error: user_canceled: no_renegotiation:

48

암호도구

• 키교환(Key Exchange):

– TLS는 Fortezza만 제외하고 SSLv3의 모든 키교환 기술을 지원

• 대칭 암호 알고리즘(Symmetric Encryption Algorithm):

– TLS는 Fortezza만 제외하고 SSLv3에서 사용하는 모든 대칭 암호 알고리즘을 포함

49

클라이언트 인증서 유형

• TLS가 certificate_request message 안에 요구하는 인증서 유형(certificatetype) – rsa_sign

– dss_sign

– rsa_fixed_dh

– dss_fixed_dh

• SSLv3에 추가로 정의되는 인증서 유형 – rsa_ephemeral_dh,

– dss_ephemeral_dh

– fortezza_kea

50

인증_확인과 종료된 메시지

• TLS certificate_verify message에서 MD5와 SHA-1 해시는 오직 handshake_messages에 대해서만 계산

• SSLv3에서는 해시 계산에 마스터 비밀과 패드를 포함

• TLS 안의 finished message는 공유하는 master_secret, 이전의 핸드셰이크 메시지 그리고 클라이언트와 서버를 식별하는 레이블을 기반으로 하는 해시

51

TLS안의 finished message 계산

PRF(master_secret, finished_label, MD5(handshake_messages) ||

SHA-1(handshake_messages))

•finished_label –client finished(클라이언트를 위한 finished_label)

–server finished(서버를 위한 finished_label)

52

암호 계산

• TLS에 대한 pre_master_secret는 SSLv3에서 계산하는 것과 동일한 방법으로 계산

• SSLv3에서와 같이, TLS 안에서 master_secret은 pre_master_secret과 2개의 hello 랜덤넘버에 해시함수를 적용해서 계산

• TLS 계산 master_secret = PRF(pre_master_secret, "master secret",

ClientHello.random || ServerHello.random)

53

TLS 암호계산

• TLS 계산 master_secret = PRF(pre_master_secret, "master secret",

ClientHello.random || ServerHello.random)

• 48바이트 의사랜덤 출력이 될 때까지 수행

• 키 블록 재료 (MAC 비밀 키, 세션 암호 키, IV)의 계산은 충분한 출력이 생성될 때까지 수행

key_block = PRF(master_secret, "key expansion",

SecurityParameters.server_random ||

SecurityParameters.client_random)

54

패딩

• 사용자 데이터를 암호화하기 전에 추가되는 패딩은 암호화될 데이터의 총 길이가 암호 블록 길이의 배수가 되게 하는 최소의 길이

• TLS에서 패딩은 총길이가 암호 블록 길이의 배수가 되기만 하면 최대 255바이트로 제한되는 어떤 길이라도 무방

55

5.4 HTTPS

• HTTPS(SSL을 이용하는 HTTP) – HTTPS와 SSL의 결합

– 웹브라우저와 웹서버 간의 안전통신 구현

– 모든 웹브라우저에 내장

– HTTPS 통신을 지원하는 웹 서버에 따라 달리 사용 • 예, 검색엔진은 HTTPS를 지원하지 않음

• URL주소가 https://로 시작

• HTTP는 80번포트

• HTTPS는 443번 포트로 SSL을 호출

56

HTTPS에서 암호화요소

• 요청 문서 URL

• 문서 내용

• (브라우저 사용자가 입력한) 브라우저 양식 내용

• 브라우저가 서버에게 보낸 쿠키와 서버가 브라우저로 보낸 쿠키

• HTTP 헤더 내용

57

연결 개시

• HTTP 클라이언트

– 적절한 포트를 통해 서버에 연결 시작

– TLS 핸드셰이크 시작을 위해 TLS ClientHello를 전송

– TLS 핸드셰이크가 마무리되면 첫 번째 HTTP 요청을 전송

– 모든 HTTP 데이터는 TLS응용 데이터로 전송

58

HTTPS 연결 수준

• HTTP 수준

– 하위계층으로 연결 요청 메시지 전달

• TLS 수준

– TLS 클라이언트와 TLS 서버 사이의 세션 설정

• TCP 수준

– 클라이언트 측 TCP와 서버 측 TCP 연결

59

연결 종료

• HTTP 클라이언트나 서버

– HTTP 레코드 안에 “Connection: close” 를 삽입해서 연결 종료

• TLS가 원격 TLS와 연결을 종료

– 하위 TCP 연결을 먼저 종료

– TLS 경보 프로토콜 close_notify 사용

60

불완전 종료

• TLS는 종료 경보를 보낸 뒤에 상대방이 종료 경보를 보낼 때까지 기다리지 않고 연결을 종료할 때 불완전 종료상태

• 하위 TCP 연결이 사전 close_notify 경보와 Connection: close 지시자 없이 종료되는 상황 – 서버 프로그램 오류

– TCP 연결중단을 일으키는 통신오류 • 모종의 공격

• 보안경고 발령 필요

61

5.5 SSH

• SSH(Secure Shell) – 비교적 쉽게 구현

– 저비용 설계된 안전한 네트워크 통신용 프로토콜

– SSH1은 안전한 원격 로그온 기능을 제공

– SSH는 보다 일반적인 클라이언트/서버 기능을 제공

– 파일 전송, 전자메일 기능을 제공

– SSH 클라이언트/서버 응용은 대부분의 운영체제에서 광범위하게 수용

62

SSH2

• SSH2

– 초기 방식의 취약점인 보안 문제 수정

– IETF RFC 4250~4256 문서 표준으로 제안

• SSH

– 원격 로그인과 X 터미널용으로 선택

– 임베디드 시스템을 제외하면 암호 기술을 사용하는 가장 널리 사용되는 응용

63

SSH 프로토콜 스택

64

SSH 구성

• 전송 계층 프로토콜(Transport Layer Protocol):

• 사용자 인증 프로토콜(User Authentication Protocol):

• 연결 프로토콜(Connection Protocol):

65

전송 계층 프로토콜

• 전방향 기밀(forward Secrecy)을 만족하는 서버인증, 데이터 기밀성과 데이터 무결성을 제공

• 전송 계층에서 옵션으로 압축이용 가능

– 전방향기밀

• 한 세션에서 세션키나 영구 개인키가 손상되더라도, 이전 세션의 기밀성에 영향을 미치지 않는 것

66

호스트 키

• 서버 인증은 공개키/개인키 쌍을 소유한 서버 전송 계층에서 수행

• 서버는 여러 개의 서로 다른 비대칭키 암호 알고리즘을 사용하는 여러 개의 호스트 키를 가질 수 있다

• 여러 호스트가 동일한 호스트 키를 공유할 수도 있다

• 모든 경우에 서버 호스트 키는 호스트 신원을 인증하기 위한 키 교환 시 사용

• 클라이언트는 서버의 호스트 공개키를 사전에 알고 있어야 한다

67

신뢰 모델

• RFC 4251에서 2가지 신뢰 모델을 제시

– 신뢰모델 1

– 신뢰모델 2

68

신뢰 모델 1

• 클라이언트는 각 호스트 이름에 대응되는 호스트 공개키를 짝지어 주는 로컬 데이터베이스가 있다

– 장점

• 중앙집중식 기반구조나 제3의 조정기관 필요 없음

– 단점

• 이름-키 쌍 데이터베이스 관리 부담

69

신뢰 모델 2

• 호스트 이름-키 연관관계가 신뢰된 인증기관(CA)에 의해 인증

• 클라이언트는 오직 CA의 루트 키만 알고 있으며 CA가 인증한 모든 호스트 키 검증가능 – 관리문제를 완화

• 이상적으로 클라이언트는 오직 하나의 CA 키만 안전하게 저장하면 되기 때문

– 각 호스트 키는 인가 이전에 미리 중앙기관에 의해 인증이 가능해야 함

70

패킷 교환

• SSH 전송 계층 프로토콜 과정 – 클라이언트는 서버와 TCP 연결을 설정

• 연결은 전송 계층 프로토콜이 아니라, TCP 연결을 통해 이루어짐

– 일단 연결이 설정되면, 클라이언트와 서버는 패킷이라 불리는 TCP 세그먼트의 데이터 필드를 통해 데이터를 교환

– 암호화 알고리즘 협상이 완료되면, MAC 값을 계산하고 그 뒤에 (MAC 필드를 제외한)전체 패킷을 암호화

71

패킷의 형식

• 패킷 길이(Packet Length):

• 패딩 길이(Padding Length):

• 페이로드(Payload):

• 랜덤 패딩(Random Padding):

• 메시지 인증 코드(MAC: Message Authentication Code):

72

SSH 전송 계층

프로토콜 패킷 교환

73

SSH 전송 계층 패킷 교환 단계1

1. 식별 문자열 교환(identification string exchange)

– 클라이언트가 패킷 교환을 시작하면서 다음 형식의 식별자를 보낸다

SSH-protoversion-softwareversion SP comments CR LF

공백 문자(space character)

리턴(carriage return)

라인피드(line feed)

74

SSH 전송 계층 패킷 교환 단계2

2. 알고리즘 협상(algorithm negotiation) – 양쪽은 각각 지원가능한 알고리즘을 선호도

순으로 정렬한 목록을SSH_MSG_KEXINIT에 포함시켜 상대방에게 전송

– 각 암호 알고리즘 유형마다 목록 존재

– 알고리즘 목록 • 키 교환

• 암호

• MAC 알고리즘

• 압축 알고리즘

75

SSH 전송 계층 프로토콜 패킷 구성

76

SSH 전송 계층 암호 알고리즘

77

SSH 전송 계층 패킷 교환 단계3

3. 키교환(key exchange)

– 2가지 Diffie-Hellman 키 교환 버전만 규정

78

키 교환 용어

• 용어 – C는 클라이언트 – S는 서버 – 𝑝는 안전한 큰 소수 – 𝑔는 서브그룹 𝐺𝐹(𝑝)의 생성자(generator) – 𝑞는 서브그룹 위수(order) – V_S는 S의 식별 문자열 – V_C는 C의 식별 문자열 – K_S는 S의 호스트 공 개 키 – I_C는 C의 SSH_MSG_KEXINIT 메 시 지 – I_S는 S의 SSH_MSG_KEXINIT로 키 교환 단계 이전에 교환 – 𝑝, 𝑔 와 𝑞는 알고리즘 협상을 통해 클라이언트/서버가 결정 – 해시함수 hash( )도 알고리즘 협상 과정에서 결정

79

키 교환 단계

1) C는 랜덤넘버 𝑥 (1 < 𝑥 < 𝑞)를 생성하고 𝑒 = 𝑔𝑥mod 𝑝를 계산한다. C는 S에게 𝑒를 전송

2) S가 하는 일 1) 랜덤넘버 𝑦 (0 < 𝑦 < 𝑞)를 생성 2) 𝑓 = 𝑔𝑦mod 𝑝 를 계산 3) 다음을 계산(𝑒 수신 후)

• 𝐾 = 𝑒𝑦mod 𝑝 • H =hash(V_C ‖ V_S ‖ I_C ‖ I_S ‖ K_S ‖ 𝑒 ‖ 𝑓 ‖ 𝐾)

4) 자신의 개인키로 H에 대한 서명 𝑠를계산 5) (K_S ‖ 𝑓 ‖ 𝑠)를 C에게 전송

80

키 교환 단계

3) C가 하는 일

1) 인증서나 로컬 데이터베이스를 이용하여 K_S가 S의 실제 호스트 키인지 검증

2) 다음을 계산하고 서명 𝑠를 검증 • 𝐾 = 𝑓𝑥mod 𝑝

• H =hash(V_C ‖ V_S ‖ I_C ‖ I_S ‖ K_S ‖ 𝑒 ‖ 𝑓 ‖ 𝐾)를 계산하고 H에 대한 서명 s를 검증

3) SSH_MSG_NEWKEYS 패킷을 교환하여 상호 간에 키 교환 종료(end of keyexchange)

81

키 교환 단계의 결과

• 양쪽은 마스터 키 𝐾를 공유

• 부가적으로 서버가 클라이언트에게 인증

82

SSH 전송 계층 패킷 교환 단계4

4. 서비스 요청(service request)

– 클라이언트는 사용자 인증이나 연결 프로토콜 요청을 위해 SSH_MSG_SERVICE_REQUEST 패킷을 전송

– 이어서 모든 데이터는 SSH 전송 계층 패킷의 페이로드에 실어 교환

• 암호화하고 MAC으로 보호

83

키 생성

•

84

사용자 인증 프로토콜

• 사용자 인증 프로토콜(User Authentication Protocol)에서는 클라이언트가 서버에게 인증 받는 수단을 제공

85

메시지 유형과 형식

• 3가지 메시지 유형

– SSH_MSG_USERAUTH_REQUEST(50)

– SSH_MSG_USERAUTH_FULLURE(51)

– SSH_MSG_USERAUTH_SUCCESS(52)

86

메시지 유형 1

• 클라이언트가 보내는 인증 요청 형식

바이트(byte) SSH_MSG_USERAUTH_REQUEST(50)

문자열(string) 사용자 이름(user name)

문자열(string) 서비스 이름(service name)

문자열(string) 방법 이름(method name)

.... 방법별 필드들

87

메시지 유형 2

• 하나 이상의 인증 방법을 요구할 경우 서버는 다음 형식으로 메시지를 보낸다

바이트(byte) SSH_MSG_USERAUTH_FULLURE(51)

이름-목록(name-list) 계속될 수 있는 인증들

불리언(boolean) 부분적 성공

88

메시지 유형 3

• 만약 서버가 인증을 수용하면, 한 바이트 메시지인 다음을 전송

SSH_MSG_USERAUTH_SUCCESS(52)

89

메시지 교환

1. 클라이언트는 방법 이름 문자열이 ‘none’인 SSH_MSG_USERAUTH_REQUEST를 전송

2. 서버는 사용자 이름이 유효한지 검사하며, 유효하지 않으면 부분 성공 필드 값을 거짓(false)으로 설정하여 SSH_MSG_USERAUTH_FULLURE를 전송

3. 서버는 SSH_MSG_USERAUTH_FULLURE를 반환

90

메시지 교환

4. 클라이언트는 인증 방법 중 하나를 선택하고, 선택한 방법 이름과 그 방법에 필요한 필드와 함께 SSH_MSG_USERAUTH_REQUEST를 전송

5. 인증에 성공 후 추가 인증 방법을 요구하면, 서버는 부분 성공 필드 값을 참(true)으로 설정하여 단계 3을 수행

6. 요구된 모든 인증이 성공하면, 서버는SSH_MSG_USERAUTH_SUCCESS 메시지를 송신하고 인증 프로토콜을 종료

91

인증 방법

• 서버는 다음 중 한 가지 이상의 인증 방법을 요구

– 공개키(publickey):

– 패스워드(password):

– 호스트기반(hostbased):

92

연결 프로토콜

• SSH 연결 프로토콜(Connection Protocol)

– SSH 전송 계층 프로토콜상에서 수행

– 안전한 인증 연결이 되어 있다는 것을 가정

– 이와 같은 안전한 인증 연결을 터널(tunnel)이라고 하는데 연결 프로토콜이 여러 논리적 채널을 다중화할 때 사용

93

채널 메커니즘

• 터미널 세션 같은 SSH를 사용하는 모든 유형의 통신은 별도의 채널을 사용하여 지원

• 양쪽에서 모두 채널을 열 수 있다

– 각 채널에서 양쪽에서는 유일한 채널 번호를 연관

• 양쪽의 채널 번호가 같을 필요는 없다

• 채널 흐름은 윈도우 메커니즘을 이용하여 제어

94

채널이 작동하는 3단계 과정

• 채널 오픈

• 데이터 전송

• 채널 종료

95

채널 오픈

• 신규 채널 오픈(open a new channel)

바이트(byte) SSH_MSG_CHANNEL_OPEN

문자열(string) 채널 유형(channel type)

uint32 송신자 채널(sender channel)

uint32 초기 윈도우 크기(initial window size)

uint32 최대 패킷 크기(maximum packet size)

... 채널 유형에 따른 데이터

부호 없는 32비트 정수 96

원격지에서 채널을 개시

• 원격지에서 다음 메시지를 반환

SSH_MSG_CHANNEL_OPEN_CONFIRMATION

– 이 메시지에는 들어오는 트래픽의 송신 채널 번호, 수신자 채널 번호, 윈도우와 패킷 크기가 포함

• 채널 개시가 불가하면 원격에서는 실패 원인을 나타내는 원인 코드(reason code)와 함께 다음 메시지를 반환한다

SSH_MSG_CHANNEL_OPEN_FAILURE

97

데이터 전송

• 채널이 개시되면, 다음 메시지를 이용해서 데이터 전송을 시작

SSH_MSG_CHANNEL_DATA

• 이 메시지에는 수신자 채널 번호와 데이터 블록이 포함

• 채널이 열려 있는 동안 이 메시지는 양 방향으로 전송

98

채널 종료

• 어느 한 쪽에서 채널 종료(close a channel)를 원하면, 수신자 채널 번호가 포함된 다음 메시지를 전송한다

SSH_MSG_CHANNEL_CLOSE

99

SSH 프로토콜 메시지 교환

예

100

채널 유형

• SSH 연결 프로토콜 규격에서 인식되는 4 가지 채널 유형 – 세션(session):

• 프로그램 원격 수행

– x11: • X 윈도우 시스템

– 포워드된-tcpip(forwarded-tcpip): • 원격 포트 포워딩

– 직접-tcpip(direct-tcpip): • 로컬 포트 포워딩

101

포트 포워딩

• 임의의 안전하지 않은 TCP 연결을 안전한 SSH 연결로 변환

• SSH 터널링이라고도 함

• 포트(port)는 TCP 사용자의 식별자

• SSH는 두 가지 유형의 포트 포워딩을 지원

– 로컬 포워딩(local forwarding)

– 원격 포워딩(remote forwarding)

102

포트 포워딩 기본 개념

103

포트 포워딩 기본 개념

104

로컬 포워딩

• 클라이언트가 하이재킹(hijacking) 프로세스를 설정할 수 있도록 해준다 – 선택한 응용층의 트래픽을 가로채어, 안전하지 않

은 TCP 연결을 안전한 SSH 터널로 방향 전환한다

• SSH는 선택된 포트로 들어오는 입력을 대기하도록 설정

• SSH는 선택된 포트를 사용하는 모든 트래픽을 받아서 SSH 터널을 통해 전송

• SSH 서버는 들어오는 트래픽을 클라이언트 응용이 지정한 수신 포트로 전송

105

로컬 포워딩 예

• 상황

– 사용자는 데스크톱의 전자우편 클라이언트이고, POP을 통해 메일 서버로부터 전자우편을 가져오기 위해 데스크톱을 사용

– POP3에 할당된 포트 번호는 110

– 다음과 같은 방법으로 이 트래픽을 보호한다

106

트래픽 보호절차

1. SSH 클라이언트가 원격 서버로의 연결을 설정

2. 사용하지 않는 로컬 포트 번호(9999라고 하자)를 선택하고, 이 포트로부터서버의 110번 포트를 목적지로 하는 트래픽을 허용하도록 SSH를 설정

3. SSH 클라이언트는 SSH 서버에게 목적지로의 연결을 생성하도록 통지 – 이 경우 메일 서버 포트는 110

107

트래픽 보호절차

4. 클라이언트는 로컬 포트 9999로 가는 임의의 비트를 받아서 암호화된 SSH 세션 안에 있는 서버로 전송 – SSH 서버는 수신된 비트를 복호화하여 평문을

110번 포트로 전송

5. 다른 쪽에서는 SSH 서버가 110번 포트를 통해 수신한 모든 비트를 SSH 세션 안에서 클라이언트에게 반환 – 클라이언트는 이를 복호화해서 9999번 포트에

연결된 프로세스로 전송

108

원격 포워딩

• 사용자 SSH 클라이언트는 서버를 대신하는 역할

• 클라이언트는 주어진 목적지 포트 번호를 달고 들어오는 트래픽을 수신하여 올바른포트에 위치하도록 한 뒤 사용자가 선택한 목적지 포트로 전송

109

원격 포워딩 예

• 집에 있는 컴퓨터에서 직장 서버에 접속

– 직장 서버가 침입 차단 시스템 뒤에 숨겨져 있기 때문에 집 컴퓨터의 SSH 요청을 수락하지 않는다

– 원격 포워딩을 사용하여 직장 컴퓨터로부터 집 컴퓨터로 SSH 터널을 설정할 수 있다

110

원격 포워딩 절차

1. 직장 컴퓨터에서 집 컴퓨터로 SSH 연결을 설정 – 이것은 보호되어 나가는 연결(outgoing connection)

이므로 침입 차단 시스템은 이를 허용

2. SSH 서버는 로컬 포트(예를 들면 22번)를 수신가능 상태로 만들어, 원격 포트(예를 들면 2222번) 주소로 향하는 SSH 연결을 통해 데이터를 전달하도록 설정

3. 이제 집 컴퓨터에서, 2222번 포트에서 트래픽을 받아들이도록 SSH를 설정

4. 직장 서버로 원격 로그온 하는 데 사용할 SSH 터널 설립 완성

111