2018년 1월 17일 수요일

번역: SYN 패킷 처리 실제​

업데이트 (1/19/2018)

이 글은 회사 공식 블로그에 게시 되었습니다. 중복을 피하기 위해서 이 포스트의 글은
아래 링크에서 읽어 주세요.
https://blog.cloudflare.com/syn-packet-handling-in-the-wild-kr/

2017년 11월 25일 토요일

아이폰X

기존에 쓰던 6이 물에 빠져서 5로 간간히 버티고 있다 드디어 아이폰X로 갈아타게 되었습니다. 모델번호가 두배가 된만큼 기대도 큰데 써본 소감을 간단히 정리하면...

일단 5대비 무지 빠릅니다. 5가 2012년 출시 제품이니 이건 당연할 거고, 카메라는 포트레이트 모드가 대박이네요. 그리고 라이브포토에서 소리도 녹음되는줄 몰랐습니다. 근데 이건 기존 시리즈에도 있는 것이라, 기존 대비 크게 다른 점은 페이스ID를 통한 인증과 홈버튼이 없어졌다는 점일 것입니다.

페이스ID는 실제 셋업해 보면 별 딜레이를 (아주 빠르게 열어 보려면 약간의 대기시간이 있는데 실 사용에 지장 있을 수준은 아닙니다) 거의 느낄 수 없고, 약간의 각도가 있어도 잘 열리는데 가령 차에서 네비용으로 옆에 달아두었을 때에는 얼굴과 직선으로 되어 있지 않아도 잘 열립니다. 터치ID의 대용이 되는데 시티은행 앱이나 뱅크오브아메리카는 이미 페이스ID로 로그인 가능하고, 국내 은행은 역시 좀 기다려야 할 것 같네요. 터치 ID는 사실 쳐다보지 않아도 된다는 점에서 꼭 봐야 한다는 건 약간 불편할 수 있겠네요.​

이보다는 홈버튼이 제거된 것이 UI적 측면에서는 더 큰 변화라 할 수 있겠습니다. 물리 버튼이 없고 애초에 베젤도 매우 얇아서 전면은 거의 화면만 보이게 되었습니다. 많이 지적되는 M자형 탈모...는 생각보다 거슬리지 않습니다. 앱에서 쓰는 화면이 잘린 것도 아니고 상단 ​상태바의 여러 아이콘들이 양쪽으로 갈라져 배치되어 있고 칸이 없다 보니 이통사 이름같은건 기본으로 보이지 않는 문제점이 있는데 실 사용에는 거슬리는 수준이 아닙니다.

홈버튼이 없는 대신 동일한 동작은 기기 아래에서 위로 쓸어올리는 형식으로 변경 되었고 기존에 그 방법으로 부르던 제어 센터는 위에서 이야기한 대로 우상단에서 쓸어 내리는 방식으로 변경이 되었습니다. 이건 오히려 좋은데 왜냐하면 우상단이라는 명확한 위치가 있어서... 그리고 ​소소한 변경 중에 앱 목록 제어가 있는데, 홈버튼 동작 같이 아래에서 위로 쓸어 올린 후 약간 그대로 대기하면 앱 목록이 나옵니다. 목록은 좌우로 쓸어 볼 수 있는데, 기존에 앱 종료하는 동작이 위아래​로 던지는 거였는데 이게 없어지고 해당 앱 스크린샷을 누르고 있으면 좌상단에 - 표시가 나오고 그걸 클릭하는 2단계로 바뀌었습니다. 왜 그걸 바꾸었는지 잘 모르겠네요. iOS는 사실 앱 종료라는게 필요 없긴 하지만 가끔 쓸 때가 있어서 (특히 회사에서 테스트 용으로...) 한단계 더 늘어난 건 좀 불필요해 보입니다. 이건 업그레이드로 해결 되었으면 좋겠네요.

그 외에는 별 불만 사항 없고 좋습니다. 아이폰5는 iOS 10 까지만 업그레이드가 되는지라 iOS 11 을 폰에서 처음 써 보는 것도 좋은 경험이고요. 버그가 많다고 하는데 딱히 접한 적은 없고 제어센터가 좀 난잡해 보이긴 합니다.

위 두가지의 급격한 변화 때문에 실험작 취급 받긴 합니다만 전반적인 첫인상은 매우 좋습니다. 그렇다고 향후 10년의 미래다... 라고 이야기 하기에는 안드로이드에 이미 유사한 변화가 많은지라 쉽게 이야기하기는 어려운데, 위와 같은 ​실험적인 시도를 사용자 경험에 불편한 변화 없이 잘 반영한 점은 역시 애플이라 생각이 듭니다.

2017년 2월 14일 화요일

HTTPS로​ 업그레이드하기​

크롬이 ​최근 업데이트에서 예고한 대로 HTTP 페이지에 암호 입력 폼이 있을 경우 안전하지 않다는 경고를 주소창 앞쪽에 붙이고 있습니다.


우리나라에서는 알고 있었는지 모르고 있었는지 모르지만 크롬 업데이트 (한국의 크롬 브라우저 점유율은 많이 높아져서 ​50% 정도 라고 합니다) 이후 주로 네이버 홈 페이지를 중심으로 기사화가 되고 있습니다.


한겨레 기사를 바탕으로 한 아래와 같은 반론 글도 접할 수 있고요.


HTTPS 로 업그레이드하기

국내에는 주로 웹사이트를 HTTP로 제작하고 HTTPS의 경우 비용이나 성능 등의 문제를 들어 꼭 필요한 부분 (로그인, 결제 등)만 HTTPS 처리를 하는 것이 일반적인데 비해, 주로 영미권에서는 도청이나 검열 문제를 들어 사이트 전체를 HTTPS화하는 움직임이 이미 몇년전부터 있어 왔고, 크롬의 업데이트도 그런 이동을 가속화하고자 하는 취지가 아닌가 합니다.

성능 저하에 대한 우려


SSL/TLS의 성능 문제에 대해서는 아래 사이트에서 많은 내용을 찾아볼 수 있습니다.


현재로서는 적당히 좋은 하드웨어를 사용하는 경우 SSL화로 인한 CPU 부하는 1%, 네트워크에 추가로 전송되는 데이터는 2% 정도라고 합니다. 서버 하드웨어의 경우 CPU에서 지원하는 하드웨어 가속 기능 등을 충분히 활용할 경우라 볼 수 있겠습니다.

따라서 성능의 경우 현재는 많은 부분이 선입견이라 할 수 있고, 실제 문제는 다음과 같은 점에 있지 않을까 합니다.

  • 신규로 TLS를 설정하는 번거로움
  • 인증서 구매 및 정기적으로 업데이트하는 번거로움

각각의 경우에 대해서 요즘 많이 이용되는 방법을 알아보도록 하겠습니다.​

신규로 TLS를 설정하는 번거로움

신규 TLS 설정은, 일단 웹서버에 TLS 기능을 넣는 것부터 시작해서, 웹사이트가 100% TLS에서 잘 동작 하는지, HTTP 로 접속하는 경우 자동적으로 HTTPS로 리다이렉트가 되는지, 주된 사용자 계층에서 접속에 문제가 없는지 확인하는 등등의 작업이 포함 됩니다.

TLS 의 최근 이슈는 주로 보안 관련인데, OpenSSL을 사용하는 경우 업데이트가 최신 버전까지 되어 있는지 확인 하고, 설정 후에 꼭 ssllabs 를 이용해서 사이트의 TLS 보안 수준을 확인 하는 것이 좋습니다. A+ 로 만드는 것이 최종 목표이지만 이용자 환경에 따라 그렇지 못한 경우가 있다는 점도 주의해야 할 것입니다.


테스트 할 사이트는 인터넷 접속이 가능해야 하며, 공개 기록을 남기지 않으려면 ​Hostname 아래에 있는 체크 박스를 꼭 체크 하도록 하세요.

TLS 설정에는 여러가지 옵션이 있고 Cipher List 등, 웹 서버별 설정이 번거로운 점이 많습니다. 일단 오픈 소스 웹 서버 (nginx, lighttpd, apache 중 하나)를 사용한다면 일단 아래 사이트의 내용을 복사해서 쓰세요.

Cipherli.st Strong Ciphers for Apache, nginx and Lighttpd

위 사이트의 설정 파일을 사용한다면 대부분 문제는 없습니다만 (SSLLabs 에서 A+ 받을 수 있는 수준입니다) 반대로 오래되거나 취약한 암호 알고리즘 등을 모두 배제하고 있으므로 오래된 브라우저 (XP + IE 6 등)에서는 아예 접속이 안될 수 있습니다. 이점 유의해서 작업 하면 됩니다.

인증서 구매 및 정기적으로 업데이트하는 번거로움

사실 이게 더 문제일 수 있는게, 비용도 그렇지만 정기적으로 (보통 1년) 업데이트를 해야 하기 때문에 관련 예산이 확보되지 못한 공공기관이나 소규모 회사, 또는 별도의 웹사이트 관리자가 없는 경우 라면 인증서가 만료된 이후에도 업데이트가 제때 이루어지지 않을 수 있으므로 더 문제가 생길 수 있습니다. HTTP 로 만들어진 사이트면 서버만 돌아가고 해킹만 당하지 않으면 몇년동안 방치해도 괜찮을 수 있지만 HTTPS로 바꾸면 정기적인 인증서 관리는 필수가 됩니다.

웹사이트용 SSL인증서는 인터넷에서 쉽게 구매할 수 있지만 역시 비용이 문제가 되고, EV Multi Domain과 같이 추가 비용이 드는 경우도 있습니다.

여기에 대한 대안으로 StartSSL과 같은 ​무료 인증서 발급 기관도 있었으나 보안상 문제가 있어서 지금은 사용하지 않는 것이 좋으니, 직접 구매해서 설치하는 경우를 제외하면 다음과 같은 선택지가 있습니다.
  • 클라우드 업체에서 제공하는 인증서를 이용하기
  • CDN 업체에서 제공하는 HTTPS 서비스를 이용하기
  • Let's Encrypt 를 이용하여 직접 발급 받기

클라우드 업체에서 제공하는 인증서를 이용하기

AWS 의 경우 자체적인 인증서 발급 서비스를 이용할 수 있습니다. ELB와 CloudFront 서비스에 붙이고 웹사이트 주소를 바꾸는 방식이 되겠지요. 다만 자체 발급되는 만큼 직접 키를 다운받을 수는 없으므로 다른 서비스에 이용하거나 자체 웹사이트에 적용은 불가능합니다.

CDN 업체에서 제공하는 HTTPS 서비스를 이용하기

CDN은 웹사이트 앞단에 존재하기 때문에 오래 전부터 SSL서비스를 제공해 왔습니다. 일정 규모가 있는 CDN회사는 모두 SSL서비스를 하고 있으니, 이용하고 있는 CDN회사가 있다면 직접 문의해 보시면 SSL에 대한 해결책을 얻을 수 있을 겁니다. 보통은 다음 3가지 중 전부 내지 일부를 제공할 것입니다.
  • 와일드카드 인증서에 고객 도메인 추가. 가격은 저렴하고 직접 인증서를 발급받을 필요는 없지만, 인증서 내용에 자신의 것이 아닌 도메인도 잔뜩 포함되어 있을 수 있습니다
  • 직접 보유한 인증서 업로드 또는 제휴된 인증서 회사를 통한 발급 후 인증서 업로드​
무료로 HTTPS 서비스를 받으려면 현재로서는 CloudFlare 가 ​제일 좋은 해결책입니다. 무료 플랜에서도 SSL지원이 되므로 개인 웹사이트 등을 손쉽게 전환이 됩니다. HTTP 웹사이트를 이미 갖고 있다면, CF에 가입해서 SSL 서비스를 활성화 하고 DNS를 전환하는 작업이 필요하게 됩니다.
CF는 와일드카드 인증서를 쓰고 있으므로 ​인증서 조회하면 인접한 도메인도 보이게 될 것이고, 키를 다운받을 수는 없습니다.

Let's Encrypt 를 이용하여 직접 발급 받기

개인 웹사이트라면 ​Let's Encrypt 를 통해서 무료로 인증서를 발급받을 수 있습니다.


웹사이트에 파일을 직접 올릴 수 있는 권한 정도만 있으면 인증서를 발급받을 수 있습니다만, 3개월 후 만료되는 짧은 인증서를 발급해 주므로 3개월마다 갱신하는 일이 필요 합니다. 이는 certbot 을 이용해서 자동화할 수 있으므로, 홈페이지가 있는 서버에 프로그램을 설치할 수 있다면 주기적으로 업데이트하는 것 만으로 인증서 관리가 쉬워 집니다. 

아래 사이트에 접속해서 운영체제와 사용하는 웹 서버를 선택하면 인증서 발급 방법이 안내 됩니다.



끝으로


HTTP 사이트를 HTTPS 화 하는 몇가지 최근 방법을 살펴 보았습니다. 시대는 흘러 흘러 이미 HTTP/2 로 가고 있는데, HTTP/2 에서는 TLS가 필수 이므로, 일단 사이트를 HTTPS 전용으로 만들 수 있다면 HTTP/2는 웹 서버 소프트웨어 업그레이드 정도만 남겨 놓았다고 보면 됩니다. 시간이 되면 그 부분에 대해서도 별도로 글을 작성 하도록 하겠습니다.