이석복 네트워크 (23)SSL, https, firewall

===

http://ocw.hanyang.ac.kr/?course=8437

 

===

App layer가 있고

tr 대표 TCP

Net 대표 IP

 

가장 중요한 허리부분에서 대표적인 프로토콜이 TCP와 IP기 때문에

TCP/IP protocol stack이라고 한다 = 이게 한 학기동안 한것

 

===

우리가 인터넷을 사용한다고 하면 100% 웹브라우징을 하는 것이다

App layer에서 HTTP request, response메시지를 주고받는게 99.9%

 

HTTP protocol은 TCP기반의 통신이다. HTTP는 TCP에서 제공하는 서비스를 이용할 수 밖에 없는 운명

TCP에서 제공하지 않는 기능은 HTTP가 사용 못해

 

(왼쪽 그림)HTTP request, reponse메시지가 TCP socket을 통해 TCP로 내려가서 통신이 되는 것

TCP제공해주는거 많지 좋아

근데 보안을 제공 안해줘. 모니터링하는 사람들 눈에 다 보여. 암호화 제공 안해줘서 wireshark키고 있으면 친구들 어디 접속하는지, 패킷 내용 다보여

 

처음부터 TCP/IP에서 보안 제공해주지 않았기 때문에 어쩔 수 없어서 응급처방으로 밴드 하나 붙인게 SSL

오른쪽 그림처럼 Application와 TCP사이에 SSL이 들어간 것. 새로운 계층은 아니고 App layer에서 존재하는 라이브러리다

근데 계층처럼 생겨서 secure socker layer = SSL

 

TCP에 그냥 내려보내면 보안이 안되니까 암호화 시켜서 내려보낼 수 밖에 없고 중간에 라이브러리인 SSL을 거쳐서 한다

원래 기존의 plain text message가 SSL인터페이스로 들어가면 SSL이라는 라이브러리에서 encryption이든 보안적인 기능을 한 이후에 알아서 TCP socket으로 내려보내준다

TCP에서 암호화를 제공 안해주니까 암호화 시켜서 내려보내야 하는데 암호화는 알고리즘, 펑션을 일일이 코딩할때마다 내가 만들면 시간낭비니까 누구 하나가 제대로 만들어놓고 그걸 통해서 내려가면 암호화되게 하는게 낫다 그게 라이브러리

 

라이브러리 쓰면 된다고~

 

===

요즘에는 SSL보다 TLS라는 용어를 더 많이 사용한다

Transport Layer Security, 결국 TCP를 사용하는데 거기에 보안을 준 기능이니까

 

===

HTTP 메시지를 SSL를 통해서 내려보내면 HTTPS가 된다

HTTPS = HTTP + SSL

진짜 별거 아니네

 

===

빨간색 글씨

- 통신이 시작되고

- 키를 생성하고

- 데이터 주고받고

- 끝내고

 

===

handshake

SSL통신을 위해서 필요한 최초의 준비동작

TCP기반이기 때문에 TCP위에서 메시지가 왔다갔다 해서 미리 TCP connection이 미리 있어야한다

이런 메시지들이 왔다갔다 하기 위해선 이전에 이미 TCP connection이 생성돼 있어야 한다

TCP SYN ->

<- TCP SYN ACK

이 다음에 저 hello가 가는 것. = 나 너랑 SSL로 교신 하고 싶다

그럼 서버가 알았어. 내 public key 인증서를 하나 줄게

 

===

인증서엔

나는 구글쩜 컴이고

내 키는 뭐뭐다

이게 가장 중요한 정보. 여기에 인증기관의 디지털 시그니처가 담기면 된다(인증기관의 private key로 encryption됐다)

 

그럼 나는 인증서를 받았을때 인증기관의 public key로 풀어서 풀리면 어 정말 쟤의 공개키가 이게 맞구나 확신한다

 

===

그럼 Alice는 Bob의 공개키를 받았으니

내가 시크릿 키를 만들어내서 이걸 Bob의 공개키로 암호화해서 보내면 Bob밖에 못 푼다

 

그럼 A와 B사이에 비밀키를 만들 수 있다

이 만든 비밀키로 symmetric key encryption한다

 

===

근데 저 만든 비밀키로 서버와 클라사이에 모든 통신에 쓰는게 아니고 이 키를 사용해서 4가지 종류의 키를 만들어낸다

만들어 내는 방법은 공개된 function이 하나 있다

비밀 키만 알면 저 4가지 키가 자동으로 나온다

 

각각의 키들의 역할은

- 클->서 data를 encryption

- 클->서 data의 integrity를 체킹하기 위한 Message Authentication Code를 만들기 위한  --좀 있다 설명

- 서->클 data를 encryption

- 서->클 data의 integrity를 체킹하기 위한 Message Authentication Code를 만들기 위한

 

그냥 비밀키를 다 쓰면 되는데 왜?

혹시라도 키가 유출됐을 때 피해를 최소화 하기 위함

이렇게 하면 유출되더라도 범위가 제한적이야

 

===

어쨌든 핵심은 handshake를 통해 서버의 공개키를 알게 돼서 서버가 누군지 확신

 : 현재 HTTPS secure 통신의 표준. 서버가 클라이언트한테 자기자신을 인증하고 있다

▽클라이언트가 요청하지만 인증은 서버가 해야하네

 

근데 우리나라는 항상 좀 반대인게

우리나라의 금융기관은 반대로 우리가 인증서 제공한다. 제공하는 사람이 귀찮기 것이기 때문에 기관이 편한 것

단점 : 지금 우리가 얘기하는게 은행인지 아닌지 몰라, 그래서 뉴스에 피싱사이트 어쩌고가 나옴

은행이 자기자신을 인증 안해주니까 사용자가 곤란

왜 이렇게 할까? 그냥 하나의 생태다. 정책과 돈이 섞인. 보안 업체들이 먹고 살아야되니까

결국 나중엔 세계 추세를 따를 수밖에 없다

 

===

message, segment라고 부르듯이 여기 SSL에서 전송단위는 record인데

 

4가지 만든 키를 갖고 app message가 들어오면

record를 만들어서 내려보낸다

record는 이렇게 생겼고 저 DATA는 app layer message다

전엔 TCP한테 저 DATA만 내려갔는데, 이젠 SSL record형태로 앞에 length붙고 뒤에 MAC붙어서 내려간다

 

MAC이 Link layer의 MAC이 아니고, 보안에서 쓰는 Message Authentication Code

 

===

MAC은 data를 Hash function에다가 집어넣어서 나온 값 H(data)

MAC이 결국 receiver가 받았을 때

- 중간에 수정되지 않은걸 확인하고 : MAC풀어서 data랑 같나 확인하는건가? 그럼 MAC만 보내면 되잖아

- 정말 그 사람이 보낸건지 확인하기 위한건데 : 암호화 풀면 걔가 보낸거니까

 

단순히 Hash Function H()에 data만 넣으면 attacker가 data 고친다음에 MAC도 생성할 수 있다 Hash function공개된거니까, MAC도 새로 만들어서 붙이면 고칠 수 있는거잖아

 

그래서 H()에 넣을 때 data랑 같이 아까 handshaking으로 생성한 클라이언트와 서버사이의 키를 같이 붙여서

H(data+SKey)

이건 C/S만 만들 수 있어. 키를 갖고 있지 않으면 못 만들어

 

저렇게 보내면 어태커가 중간에 고치면 들킨다. 어태커는 제대로된 MAC을 만들수가 없으니까 SKey가 없어서

 

그리고 handshaking해서 만든 4개중에 한개의 키를 써서 암호화해서 보내면 암호화된 메세지가 내려간다 : ??

 

===

큰 그림으로

TCP의 segment가 HDR + DATA

DATA에 원래 app message가 들어가는데

SSL을 사용하면

SSL Record가 segment의 DATA에 들어간다

segment = HDR + length + DATA(=app message) + MAC

그럼 저기 record의 DATA부분이 app message가 됨

이게 밑으로 내려가면 IP패킷에 담긴다

 

그럼 어태커가 봤을 때 SSL 거쳤던 IP패킷을 보면

IP패킷의 헤더는 보이고

TCP헤더 보이고

record의 length까진 보이고

record의 data와 MAC이 암호화

 

어태커는 어디로 가는진 알 수 있는데 내용은 몰라

wireshark써보면 친구가 https를 써서 웹브라우징 하고 있으면 어디가는진 알 수 있는데 내용은 깨져서 나와

 

어디가는지도 숨기고 싶으면 어제 얘기했던 TOR쓰면 된다. 근데 느려서 못 써

 

===

그럼 어태커는 SSL때문에 할 수 있는 일이 제한적이 된다

 

키가 없어서 app message를 읽을 수 없어

못 읽는다고 수정할 수 있나? 수정하면 MAC에 잡혀. 수정하면 티가 나

어태커는 눈치 못채게 통신을 방해하고 싶은데, 이제 의미있는 일은 못한다. 방해하는 일 정도 뿐

 

===

방해하는 일 1 

 

클->서

SSL을 사용한 패킷이 나갈건데

패킷은 TCP기반이니까 보낸 순서가 보장되는데 두 패킷의 SSL record내용을 싹 바꾸면?

순서 바뀌어서 데이터가 들어오는데 눈치 못 챈다

 

어태커의 reordering 장난을 막기 위해

 

H()안에 seq도 같이 집어넣는다 SSL record의 순서다. TCP의 seq가 아니라

헤더에 담기는 정보가 아니고 (▽stack타고 쭉올라올 때) SSL거칠 때 트래킹하면서 카운트하는 정보다

그 순서대로 MAC이 안맞으면 중간에 누가 장난친 것

 

===

방해하는 일 2, SSL사용하고 어태커가 사용할 수 있는것 또 하나

실제로 데이터가 다 가지 않았는데 TCP FIN 메시지를 보내서 끊어버리는 것. 데이터가 다 도착한 척

돈거래 transaction인데 중간에 끊어버리면 안돼서 데이터 다 전송했는지 안했는지까지 SSL에서 책임을 져야한다

 

그래서

type이라는 필드를 두고 그냥 데이터는 0, 정말 보낼 데이터가 없을 땐 1

type까지 MAC에다가 넣는다 MAC( )여기 안에  ▽H()말하는거겠지?

 

0이 아직 도착 안했는데 TCP FIN이 와서 끊기면 이 트랜잭션 무효! 판단한다

 

MAC()안에 뭐 많이 넣는다고 해서 MAC가 길어지는건 아니다. 결국 Hash function통과시키는것. output의 크기 동일

 

===

이렇게 TCP에서 제공해주지 않는 보안 기능을 SSL이 책임진다. TLS라고도 불리고

HTTP가 이걸 사용하면 HTTPS가 되는 것

 

=== 

내가 HTTPS방식의 웹서버를 운영하고 싶으면 인증기관에 가서 사인 받아야, 인증서를 준비해야한다 certification

 

===

이 이전에 TCP SYN, SYN ACK (TCP connection)이 있다

세번째 메시지에 hello

그럼 certificate를 주고(=public 인증서)

클라이언트가 서버에 퍼블릭키 확인하고 

그걸 통해 시크릿 키 정하고 4가지 종류의 각각 다른 역할하는 키 생성해서

그 이후에 데이터 통신 이뤄진다

type0 은 데이터

seq는 헤더에 나타나지 않지만 MAC에 쓰이고

 

===

방금까지가 핵심이고

실제 SSL은 저기서 하나 더 추가되는데

처음에 키 만들 때 각자 어떤 encryption알고리즘 쓸 지 틀려서 그것에 대한 협상추가된다

negotiation

 

===

이게 큰 그림으로 잘 나타낸 것

맨 위 data : http request, response message

SSL로 넘어오면 바뀌는데

app message가 쪼개지고  --▽설명 안함 이거 그냥 패킷 쪼개지듯이 쪼개지는 그건가?

*data fragment = plain text

이 plain text를 사용해서 MAC를 만들고  ▽MAC()안엔 저거 합해서 4개가 들어갔지

encryption key를 사용해서 MAC을 포함한 data fragment + MAC을 encryption해서 encrypted data and MAC으로 만듦

 

받는 사람 측에서는 decryption key를 갖고 encrypted data and MAC을 풀어서

data fragment+MAC을 꺼내고

다른 키 갖고 MAC을 확인하고

맞으면 통과시켜서 위로 올려보낸다  --맞으면 통과시켜서가 MAC풀어서 나온 data랑 data를 같다고 하는건가?

 

===

Firewalls

 : 모니터링 필터링 디바이스

보통 하나의 네트워크의 게이트웨이에 자리를 차지해서

외부로 나가는 패킷

외부에서 들어오는 패킷

을 감시하는 것

 

게이트웨이가 길목이니까 거기에 자리잡고 모든 패킷을 모니터링 해서

통과시킬지 필터링시킬지 결정

 

===

네트워크 운영자가 뭘 통과시킬지 필터링 할지를 결정한다

이런 정책들을 firewall에다가 구현할 수 있다

 

첫번째 줄 : No outside WEb access : 웹브라우징 못하게

어떻게 구현?(Firewall Setting) : dest port가 80번인걸 Drop시켜라

 

이걸 구현하기 위해선 TCP헤더까지 봐야한다

 

원래 라우터에서는 IP헤더까지만 보는데, firewall이 등장하면서 IP헤더 이상을 보고 있다

=>firewall도 layering violation의 유명한 device중 하나, NAT와 더불어서

 

firewall은 end user가 아닌 중간애라서 IP헤더 이상 보면 안되는데 보고 행동하고 있다

 

결국은 GWR에 여러가지가 돌아가고 있다 : NAT, DHCP, DNS, firewall..

 

===

두 번째 줄 : 내부 네트워크에 유명한 웹사이트 하나만 운영할 것. 나머지는 웹사이트 운영 금지

Firewall Setting : 내부로 들어오는 TCP SYN packets다 드랍(웹서버 향한거 제외하고는 다 드랍. 그럼 여기서 웹서버 운영 못 한다)

 

결국 패킷 하나하나를 보고 패킷의 조건이 맞으면 드랍or통과

 

===

네트워크 관리자는 보수적이 된다

가장 안전한건 트래픽을 다 막는 것, 첫번째 Policy - 사용자들이 왜막았냐고 난리치니까 못 넣는다

 

ssh : telnet의 secure버전

ssh로 학교 내부에서 외부 ssh서버로 접근하는거 막혀있거든?

이건 어떻게 구현한거야? 똑같이 firewall에다가 첫번째 Policy로 구현하는데 port가 22번인것

 

여러분 왜 막아놨는데 난리안쳐요 ssh서버를 운영하겠다는것도 아니고 ssh클라이언트로 정당한 권리를 확보하겠다는건데

 

교수님이 막혀있어서 뭔가 싶어서 전화했더니 풀어줄게요 교수님 IP로 22번으로 해서 나가는거 풀어드릴게요

왜 22번 막아놨나요?

몇년전에 한국에서 어떤 기관이 대형 DDOS해킹 사건이 있었  *DDOS : 무수히 많은 트래픽이 몰린 것

봤더니 큰 역할을 한게 우리학교였대

외부에서 강의실에 남아있는 컴퓨터들 남아있는거 좀비 PC로 만들어서 ssh클라이언트로 공격했대

 

근데 이게 뭐냐면 마차타다가 자동차가 등장하니까 교통사고는 일어나는데 교통사고 우려때문에 차타지마 마차타

보안사고가 일어나면 그것에 대한 대응을 마련해야되는데 보안사고가 일어나니까 사용해야될 정당한 권리를 막았다

 

웹브라우저 HTTP 프로토콜로 보안사고나면 HTTP 프로토콜 막을건 아니잖아

 

80번은 못하면서 22번은 왜 막아놨을까 ssh쓰는 사람이 별로 없어서 학생들이 들고 일어나지 않으니까

인터넷 사용하는건 클라이언트로서의 권린데 말이 안되는 것

 

===

firewall에 들어가는 rule table

 

어떤 패킷이 등장하면 그 패킷이 어느 row인지 판단해서 그 행에 해당하는 action을 취한다

priority가 있다. 위 일수록 우선순위

첫번째 해당하면 그거

첫번째 해당x면 두번째행에 해당하는지 보고 안되면 아래로... 전부 해당 안되면 맨 마지막의 전부 all인것에 해당되겠지

 

그림의 예로는

outside of : 외부

> 1023 : 1023위의 랜덤번호

 

첫번째 줄은 외부로 나가는 웹브라우징 허용이라는 말 = HTTP request

두번째 줄은외부에서 들어오면서..  = HTTP response

=>웹 브라우징 허용

세번째 네번째는 DNS 허용

 

이것만 허용된 것. 그러므로 저 그림에선 ssh안됨

 

===

방금봤던건 패킷별로 판단 실제론 저 HTTP 패킷들 이전에 TCP connection이 있어야해

패킷만 보고 판단하면 TCP connection이 없었는데도 저런 패킷이 들어오면 통과시켜

 

그래서 좀 더 진화된 firewall은 모든 TCP connection을 tracking한다

어떤 패킷이 들어왔을 때 실제로 그것에 해당하면 TCP connection이 있는지 없는지 판단. 있으면 통과

 

그게 Stateful packet filtering

 

===

firewall에서 마음만 먹으면 어떤 사이트 블랙리스트 추가하고 할 수 있다

 

===

첫 시간에 봤던 슬라이드, 이런 용어 설명한다고 했다. 레이어 순