참고: HTTP_SSL_MODULE 문서 페이지 Nginx - Disable SSL, TLS 1.0, and TLS 1.1 Nginx에서 TLSv1과 TLSv1.1을 비활성화하는 방법 오늘은 NGINX에서 TLSv1, TLSv1.1을 비활성화하는 방법에 대해 살펴보겠다. 는 NGINX에서는 간단하게 아래와 같이 ssl_protocols값만 설정해주면 끝난다. 참고로 TLSv1.3은 OpenSSL 1.1.1 이상의 버전이 설치되어있을때만 사용 가능하며, 그 이하의 버전이 설치되어있는 경우에는 에러가 출력된다. 이럴 때는 OpenSSL을 업데이트해주거나 혹은 과감하게 TLSv1.3을 빼주도록하자. 보안보다는 퇴근이 우선이다 ssl_protocols TLSv1.2 TLSv1.3 몹시 간단하게 끝났는데, 이렇게..

OpenResty, NGINX Cross-compile에 대하여 임베디드 시스템에 OpenResty를 사용한 이후로, 칩셋이 변경될 때마다 크로스 컴파일을 다시 해줘야했다. 문제는 기반지식이 전혀 없는 상태인데다, 인수인계 문서의 거의 내용도 없었다. NGINX 자체를 크로스컴파일 하는 경우는 종종 있지만 OpenResty를 크로스컴파일하는 글은 찾기 어려웠다. 이전에도 작성했듯이 scratchbox2, qemu와 같은 툴로 환경을 설정해주면 간단하게 끝나는 일이다. 문제는 toolchain 형태로 제공되는 컴파일러의 경우, scratchbox2를 사용해서 환경설정을 하게되면 에러가 발생한다. 예를 들면 심볼릭 링크를 인식하지 못해서 컴파일러가 동작하지 않는다던가. 애석하게도 작년에 크로스컴파일을 마지막..

Spawn-fcgi의 크로스 컴파일에 대하여 spawn-fcgi는 nginx에서 다른 라이브러리를 사용하지 않고 fcgi를 돌릴 때 필요한 아이로, fcgi를 프로세스 단위로 실행해주는 녀석이다. 이 녀석을 사용하여 fcgi를 실행한 뒤, nginx에서 proxy-pass해주면 fcgi를 이용하여 통신하는 것이 가능해진다. OpenResty/NGINX를 크로스 컴파일 할 때와 마찬가지로, QEMU나 Scratchbox와 같은 툴로 에뮬레이터 환경을 구축한 뒤 컴파일하면 아무런 설정 없이 컴파일이 가능하다. Scratchbox와 QEMU에 대해서는 OpenResty/NGINX의 크로스 컴파일 할 때 알아봤으므로, 이번에는 설명을 생략하도록 하겠다. configure를 통한 설정 Scratchbox와 QEM..

가볍고 속도가 빠른 Nginx를 메인으로 사용하고, 실제 API등의 처리는 호환성 및 라이브러리가 다양한 Flask를 사용하는 환경을 구축하게 됐다. 두 개의 서버가 돌아가고 있는 상황인데, 외부에서 Flask에 직접 설정할 수 없도록 로컬 포트를 할당해준다. 그리고 Nginx의 특정 패스로 접근하면, Flask로 proxy pass하여 Flask에서 내용을 처리하도록 설정한다. 우선은 Flask 샘플코드를 사용하여, 정상적으로 실행되는지 확인하자. 아래의 코드는 Flask의 특정 경로로 접근할 시, Plain text를 반환하는 코드이다. from flask import Flask app = Flask(__name__) @app.route('/hi') def hi(): return ..

RFC2617의 Digest 인증방식은 obsolates되고 RFC7616이 나오기는 했지만, 요즘에는 Digest인증을 사용하기보다는 폼 베이스 인증방식을 쓰기도 하고, 브라우저에서 RFC7616의 Digest 인증방식을 지원하지 않아서 nginx-http-auth-digest모듈에 RFC7616방식을 구현한 브랜치가 없지 않나 싶다. 아무튼 현재로써는 구현이 필요한 상황이다. 시간나면 구현해봐야겠다. RFC2617 문서는 HTTP Authentication: Basic and Digest Access Authentication에서, RFC7616 문서는 HTTP Digest Access Authentication에서 확인이 가능하다. RFC2617기준의 Digest 인증방식에 대해 간단하게 설명하자면..