TLS 1.0 & 1.1 , L4 & L7

TLS는 뭔가요??

주요 웹브라우저에서 TLS 1.0 및 TLS 1.1 을 이용한 통신 암호화 프로토콜에 대한 지원을 종료

TLS (Transport Layer Security)는 클라이언트와 서버간의 통신을  보호하고 암호화하기 위해 사용되는

암호화 프로토콜입니다. 

넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술로, 국제 인터넷 표준화 기구에서

표준으로 인정받은 프로토콜로, 표준에 명시 된 정식 명칭은 TLS지만 SSL이라는 용어로 많이 사용되고 있습니다.

[ 나무위키 TLS 참조 ]

Google, Microsoft, Apple 브라우저에서

TLS 1.0 및 TLS 1.1 버전 지원을 중단하는 이유!!

TLS 1.0은 1999년에 나온 프로토콜이며 TLS 1.1의 경우 2006년 공개 되었습니다.

공개된지 오래 된 만큼 취약점이 많이 나온 상황이며,  2008년에 공개 된 TLS 1.2 에 비해 보안 알고리즘이 취약하여

Google, MS, Apple등은 좀 더 나은 보안을 위해 지원을 중단한다고 합니다.

(  TLS는 현재 1.0, 1.1, 1.2, 1.3(최신)으로 총4개의 버전이 있습니다. )

※ TLS 1.2 적용을 위한 최소환경
– JAVA 7
– Apache 2.2.15 (2.2.22)   *2.2.15버전의 경우 지원은 하나 상세 설정이 불가능
– OpenSSL 1.0.1
– Windows Server 2008 SP2
– Windows Embedded POSREADY 2009
– Windows Embedded STANDARD 2009
“위 버전 미만의 OS 및 라이브러리. 데몬에서는 작동하지 않으니 마이그레이션이 필요”

 

홈페이지(웹사이트)의 TLS 지원 여부를 확인하세요.

https://www.ssllabs.com/  사이트의  “Test your server”에서 운영중인 웹사이트의 도메인 입력 후 홈페이지의

TLS 지원여부를 확인할 수 있습니다.

 

1. 개요

흔히 엘포 엘세븐으로 불리는 L4, L7 스위치. 우리는 이에 대해 얼마나 알고 있을까?

이는 OSI 7 레이어(계층)와 밀접한 관련이 있다. 적어도 들어보긴 했을 것이다. Open Systems Interconnection의 약자인 ISO에서 만들었다.

• L1 : 물리 (피지컬) 계층
• L2 : 데이터링크 계층
• L3 : 네트워크 계층
• L4 : 전송 (트랜스포트) 계층
• L5 : 세션 계층
• L6 : 표현 (프레젠테이션) 계층
• L7 : 응용 (애플리케이션) 계층

위와 같이 낮은 계층일 수록 물리적이다. 반대로 높은 계층일 수록 논리적이다. 이제 이 계층에 해당하는 장비인 스위치(Switch)에 대해 정리하고자 한다.

---

2. L2 스위치

자신에게 패킷이 오면 패킷의 목적지를 확인한 후 패킷을 목적지까지 전달한다. 그런데 이더넷 레벨로 동작한다. IP 주소가 아니고 MAC 주소 기반이라는 말이다. 

단순한 형태긴 한데 그나마 허브보다는 진화한 형태이다. 허브는 더 멍청하다.. 자신에게 패킷이 오면 연결된 장비에 다 보낸다. 연결된 장비들은 일단 받은 후에 자기껀지 아닌지 확인해야 한다. 네트웍 트래픽 낭비다..

---

3. L3 스위치

L2에 비해 조금 똑똑해졌다. IP 주소 기반으로 라우팅을 할 수 있게 됐다. L3 계층의 프로토콜이 IP인 점을 기억하자..

라우터와의 역할 경계가 조금 애매모호하다.

---

4. L4 스위치

드디어 나왔다. 엘포!

L4 계층의 프로토콜은 TCP 혹은 UDP. 그래서 L4 스위치는 TCP나 UDP 프로토콜의 헤더를 보고 스위칭한다. 로드 밸런싱이 가능하다. 일반적으로 다음과 같은 밸런싱 방식을 제공한다.

4-1. Round Robin

• L4 하단에 연결된 서버에 순차적으로 접속한다.
• 하단의 서버 상태는 상관하지 않는다. (현재 세션이 몰려있던 아니던)
• 때에 따라 각 서버 별로 가중치(weight)를 부여할 수 있다.

4-2. Least Connection

• L4 하단에 현재 세션 수가 가장 적은 서버에 접속한다.

4-3. Hash(Source IP)

• 한번 연결되었던 서버는 계속 그 서버에 접속한다.
• 어느 정도 접속 사용자가 늘어나면 거의 공평한 로드 밸런싱이 가능하게 된다.
• 새로운 사용자가 들어오면 사용자 IP (혹은 +Port) 기반으로 key 값을 생성한다.

이 밖에 Response time 기반, Bandwith 기반 등의 기법이 존재하기도 한다.

로드 밸런싱 관련하여 물리 스위치 장비는 아니지만 Nginx 소프트웨어 관련하여 연구된 자료가 있으니 도움이 될 듯 하다.

관련 점검 항목은 다음과 같다.

• L4 구성을 통한 백엔드 서버(WEB/WAS 등)의 장애 대응 구성 여부
• 적절한 부하 분산 여부 (IP 주소에 따른 밸런싱 확인 등)

---

5. L7 스위치

가장 똑똑하다.

패킷 내용을 좀 더 참조하는데 예를 들면 HTTP의 URL 같은 것을 이용하여 세밀한 로드 밸런싱이 된다.

예를 들어보자.

1.   http://sarc.io/aaa -> 서버1로 보냄
2.   http://sarc.io/bbb -> 서버2로 보냄
3.   http://sarc.io/ccc -> 서버3으로 보냄

 

전반적인 차이점은 아래 그림을 보면 좀 더 쉽게 이해할 수 있지 않을까? (물론 인터넷에 떠다디는 그림이지만..)

출처 : 

https://idchowto.com/?p=46322

idchowto.com - 스마일서브(Cloudv.kr)

https://sarc.io/index.php/miscellaneous/758-osi-7-l4-l7

 

또 다른 그림.