SSH 과 SSL, TELNET, 포트별 번호

SSH 포트번호 22

Telnet 포트번호 23

 

SSH는 Telent 에서 보안성을 강화해서

나온 원격접속 방식입니다.

 

 

SSL은 

HTTPS에서 S를 하기위해 인증서가있는것입니다.

 

 

여기서 해당 자물쇠를 누르면

인증서 정보가 나옵니다.

그리고 여기서 통신자들끼리 

서로 동일한 키를 주고받아야 하죠

 

 

 흔히 카페에서 볼 수 있는 사례를 하나 들어보도록 하겠습니다

 

 

 

위에 영수증 어때요 ??

 

뭔가 패킷 같지 않으신가요 ??

패킷 내용에 근데 암호화가 안되어있는걸 확인할 수 있어요 

화장실 비밀번호랑 와이파이 비밀번호가 그대로 노출되고있습니다.

상세 주소도 그대로 노출이 되구 있구요 

 

 

그래서 생각해본것이 공개키와 암호화입니다.

 

먼저 공개키를 적용한다면 어떻게 될까요 ??

 

주소 : 서울특별시 종로구 가 아니라 

주소 : 수도 이렇게 표시를 하고 

공개키를 카페 직원이 저한테 주는 것이지요

 

그러면 저는 저는 수도라고 적혀있는 영수증 패킷을 받고

공개키로 열어서 "서울특별시"라고 해석할 거에요 

 

그런데 누군가 (해커가) 수도라고 쓴 글자를 보게 되면 

기분이 나쁠수 있어요~ 

그래서 보안을 좀 더 강화해준 것이 

Secure Socket Layer 입니다.

 

Secure layer(층)으로 가서 수도를 

★★ 로 바꿔줍니다 ,

그리고 고객은 공개키와 사설키 (private key)를 가지고있는거에요

그래서 공개키로 "수도"로 변환해서 읽고

사설키로 "서울특별시"라고 해석해주면 됩니다.

 

SFTP 도 Secure이고 

vlan에서도 secure 이 있습니다.

s가 붙으면 거의 secure이라고 봐도 될거 같아요 ~ 

 

 

 

어제 포스팅했던 포카칩 서버와 조리퐁 서버를 예로 든다면

문을 열 수있는 Public key와 private key가 필요한겁니다.

 

그리고 조금 더 현실적으로 얘기해보자면

내가 김옥돌이 맞는지 확인하는 신분증같은 역할을한다고

보면 됩니다.

 

 

 

이게 실제로 HTTPS 접속 과정 패킷을 보여주고 있는건데요~ 

 

 

 

183.111.174.9
http://s.soldesk.co.kr/login.php


HTTP
soldesk2553
------WebKitFormBoundarygbRnpinPBAMSk4oY
Content-Disposition: form-data; name="strPassword"


------WebKitFormBoundarygbRnpinPBAMSk4oY
Content-Disposition: form-data; name="FindHphone1"


HTTPS
$%^&*&*(&^*(&*(&*&**)
------WebKitFormBoundarygbRnpinPBAMSk4oY
Content-Disposition: form-data; name="strPassword"

12^%$^%%^&^!2829010921^%&*&))
------WebKitFormBoundarygbRnpinPBAMSk4oY
Content-Disposition: form-data; name="FindHphone1"




Secure
CA 암호화/복호화

클라이언트 -> soldesk2553->$%^&*&*(&^*(&*(&*&**)->서버가 받고 -> key -> 복호화 -> soldesk2553
클라이언트 -> soldesk2553 -> 서버 -> soldesk2553

SSL -> TLS 1.1 -> TLS 1.2 -> TLS 1.3

 

HTTP 같은 경우는 아이디와 비밀번호가 모두 패킷 내용에 보이는 반면

HTTPS 같은 경우는 아이디와 비밀번호가 모두 암호화 되어있기 때문에 

복호화해주는 과정이 필요합니다. 

 

 

 

근데도 HTTPS 가 가지는 (SSL)이 가지는 문제점이있어서

차세대 TLS를 사용한다고 하는데 그이유는 무엇일까요 ? 

 

 

SSL 자체가 패킷을 암호화 할때 인증서를 사용하는데 

프록시 서버를 이용하면 중간에

프록시 서버 인증서로 암호화된 패킷을 복호화할수 있는

문제가 있습니다

 

SSL STRIP 이나 SSL BYPASS 라고 하는데 

 

이와 같은 문제를 해결하기 위해서 나온 기술이 

SSL PINNING 이라고 정상적인 인증서인지아닌지 검사 하는 것입니다.

 

 

좀 더 자세히 얘기해보면 

일단 rootCA라는 인증서 가 있고

그 인증서가 암호화에 이어서 가장 중요한 인증서라고 해봅시다 

 

근데 프록시 서버에서 임의로 사용하는 rootCA를 이용해서

암호화를 하는겁니다

 

예를 들어 우너래 클라이언트와 서버 사이에 암호화가 되어있다면

 

클라이언트와 프록시, 프록시와 서버사이에 암호화가 이루어지는데

 

프록시는 클라인언트와 주고 받는 암호화된 패킷을 복호화할수있고 

 

반대로 서버와 주고 받는 암호화된 패킷을 복호화 할 수 있따는 것입니다.

 

즉 , 정리하면

 

정상적인 rootCA 가 아닌 임의의 rootCA

를 이용해서 중간에서 패킷을 복호화할 수 있다는 것입니다. 

 

 

복호화해버리면 큰일나겠쬬 ??

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

참고로 

 

WWW 서비스를 제공하는 HTTP 어플리케이션층 프로토콜이고

 80 포트 를 사용하고 TCP/UDP 트랜스포트층 프로토콜로 연결합니다 

 

HTTPS 는 똑같이 WWW 서비스를 이용하지만 보안이 추가되어있고 

포트번호는 443 번입니다 

 

FTP는 파일전송 서비스를 제공하구

포트는 20,21 포트를 사용합니다 

 

TELNET은 원격 로그인 서비스를 제공하고 

포트는 23번 포트를 사용합니다 

 

SSH 는 똑같이 원격 로그인 서비스를 제공하는데

보안이 강화된 로그인 서비스입니다 

그래서 거의 SSH를 사용합니다 보안을 신경써야한다면 말이죠 

포트는 22 번 포트를 사용합니다