Asciinema: CentOS (Python 3.4)에서 4kb 이상의 레코딩 업로드에 대한 잘못된 요청

나에게도 일어난다. ZSH를 사용하지만 OMZ는 사용하지 않습니다.

$ zsh --version
zsh 5.3.1 (x86_64-pc-linux-gnu)
$ asciinema --version
asciinema 1.4.0

tmpw6byrbv8-asciinema.json

API URL을 HTTPS에서 HTTP로 변경하면 모두 제대로 작동한다는 것을 알았습니다.

어제로드 밸런서 구성을 변경했기 때문에 관련이있을 수 있습니다.

나는 이것을 Centos 7 Vagrant VM에서 재현 할 수있었습니다. 어제부터 사용했던 Brightbox로드 밸런서 (SSL 종료, 자동 Let 's Encrypt 인증서 포함)와 관련이 있다고 생각합니다.

@andyone @ThiefMaster 지금 시도해 볼 수 있습니까? 내가 해결했을 수도 있습니다.

여전히 400 점

OpenSSL 관련 문제라고 생각합니다. curl은 SSL / TLS 작업을 위해 NSS (Network Security Services)를 사용하기 때문에 curl을 사용하여 데이터를 보내는 것은 괜찮습니다.

Brightbox로드 밸런서 사용

nginx 기반 솔루션입니까?

@andyone Brightbox로드 밸런서가 Haproxy를 사용한다고 생각합니다.

나는 이것을 일관되게 재현 할 수있다. Vagrantfile 및 지침을 만들었습니다. https://github.com/sickill/bb-lb-400

@andyone 문제는 녹음 에서이 특정 줄이 아닌 업로드 된 json 파일의 전체 크기입니다.

이 구성 으로 webkaos를 기반으로 https://ascii.kaos.io 프록시를 만들었습니다 ( BoringSSL로 향상된 nginx). My 및 @ThiefMaster 녹음이이 프록시를 통해 성공적으로 업로드되었습니다.

지금까지 내가 아는 것은 다음과 같습니다.

HTTP 요청은 Brightbox 부하 분산기를 통해 잘 진행되지만 HTTPS 요청은 400 개의 잘못된 요청을 제공합니다.
요청 본문 이 약 4KB보다 큰 요청의 경우.

흥미로운 것은 CentOS에서 HTTPS 용으로 400 개를 받고 있다는 것입니다. macOS에서 HTTPS가 제대로 작동합니다. (HTTP는 모든 곳에서 잘 작동합니다).

나는 더 깊이 들여다 보며 차이점이 무엇인지 알아 보려고 노력했습니다. 나는 tcpdump를 사용하여 CentOS와 macOS 모두에서 요청을 확인했습니다 (HTTP, 요청 자체가 HTTPS에서와 동일한 형식이라고 가정).

유일한 차이점은 macOS에서는 본문 앞에 2 개의 빈 줄, CentOS에서는 1 개의 빈 줄입니다 (아마도 이러한 OS에서 Python 3과 함께 제공되는 urllib 버전이 약간 다르기 때문일 수 있음).

CentOS :

POST /api/asciicasts HTTP/1.1
Accept-Encoding: identity
User-Agent: asciinema/1.4.0 CPython/3.4.5 Linux/3.10.0-514.16.1.el7.x86_64-x86_64-with-centos-7.3.1611-Core
Authorization: Basic <61 bytes of base64 encoded credentials>
Content-Length: 13582
Content-Type: multipart/form-data; boundary=c3f4e35afa4a4ce6b65b6420da09b46e
Connection: close
Host: asciinema.org

--c3f4e35afa4a4ce6b65b6420da09b46e
Content-Disposition: form-data; name="asciicast"; filename="asciicast.json"
Content-Type: application/json

<about 13 kb of json>

맥 OS:

POST /api/asciicasts HTTP/1.1
Accept-Encoding: identity
Content-Length: 13582
Host: asciinema.org
User-Agent: asciinema/1.4.0 CPython/3.6.1 Darwin/16.5.0-x86_64-i386-64bit
Content-Type: multipart/form-data; boundary=71d5b757e9d1451b9540dc286f74207d
Authorization: Basic <61 bytes of base64 encoded credentials>
Connection: close


--71d5b757e9d1451b9540dc286f74207d
Content-Disposition: form-data; name="asciicast"; filename="asciicast.json"
Content-Type: application/json

<about 13 kb of json>

그것이 어떤 영향을 미치는지보기 위해 LB의 "요청 버퍼 크기"를 4096 (기본값)에서 8192 (최대)로 일시적으로 변경했고 갑자기 모든 OS (모든 OS, HTTPS)에서 정상적으로 작동하기 시작했습니다.

버퍼 크기가 4096이면 이것이 사실이기 때문에 이것이 궁극적 인 솔루션이라고 확신하지 못합니다.

• 문제없이 3MB 본문으로 POST 요청을 할 수 있습니다.
  macOS의 HTTPS
• 따라서이 버퍼 크기는 요청 본문이 아닌 헤더 용이라고 가정합니다 (Brightbox의 John이 확인 함).
• 나는 문제없이 <4KB 본문으로 POST 요청을 할 수 있습니다.
  CentOS의 HTTPS
• CentOS에서 HTTPS를 통해 4KB 이상의 본문으로 POST 요청을 할 수 없습니다.
• 위의 내용은 헤더에만 적용되는 버퍼에 대한 내 가정과 모순됩니다.
• 모든 경우에 요청 헤더가 작음 (~ 330 바이트)

"요청 버퍼 크기"를 8192로 늘리면 본문 크기와 프로토콜이
중요하지 않으며 모든 것이 잘 작동합니다. 부딪혀서
8192로 시간을 벌거나 (영향받는 사람을 줄이십시오)
문제를 완전히 해결합니다 (그렇다면 왜?).

이에 대해 Brightbox에 연락하여 무슨 일이 일어나고 있는지 설명해 줄 수 있기를 바랍니다.

Brightbox 측에서 8192 버퍼 크기를 다시 업데이트하십시오.이 번호를 사용하면 CentOS에서 작동하지만 @ThiefMaster 에서는 여전히 작동하지 않습니다.

죄송합니다.

Brightbox LB를 통해 트래픽을 보내기 전에 Nginx에서 SSL을 종료했고 모든 것이 수년 동안 잘 작동했습니다. Nginx를 기반으로하는 @andyone 의 프록시와 함께 작동하는 경우 Nginx가 요청 형식에 대해 더 "용서"하는 반면 Haproxy는 더 엄격하며 asciinema 클라이언트는 Python 3.4 (및 해당 Mac에서 사용하는 3.6.1보다 오래된 urllib).

나중에 Haproxy로 확인할 수 있지만 내 버전은 OpenSSL 대신 LibreSSL로 빌드되었습니다.

내 현재 이론은 다음과 같습니다.

헤더 및 본문 앞의이 단일 새 행은 LB가 헤더 읽기를 완료하기에 충분하지 않으며 (새 행 2 개 예상), 그 아래의 모든 데이터를 헤더로 계속 읽고 바이트를 계산하며 결국 헤더의 최대 크기를 초과합니다. LB에 bytes_read (소켓에서 읽은 바이트)와 같은 변수가 있으면 헤더 읽기를 마친 후 값을 확인한 다음 본문을 읽은 후 다시 다시 확인합니다. <4kb 파일을 업로드하면 헤더에 대한 4kb 제한을 초과하지 않으며> 4kb를 업로드하면 초과합니다.
(그리고 이것은 HTTPS에서만 발생합니다)

그게 사실인지 모르겠지만 소리내어 생각 만 해요 😀

소스 코드를 업데이트하여 새 줄을 추가하고 CentOS에서 확인했지만 여전히 실패합니다. 따라서 위의 이론은 잘못되었습니다.

이것은 HTTPS를 사용하는 CentOS에서 작동합니다.

curl -v -X POST -u $USER:api-token https://asciinema.org/api/asciicasts -F [email protected]

* About to connect() to asciinema.org port 443 (#0)
*   Trying 109.107.38.233...
* Connected to asciinema.org (109.107.38.233) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: CN=asciinema.org
*   start date: Jun 07 09:12:00 2017 GMT
*   expire date: Sep 05 09:12:00 2017 GMT
*   common name: asciinema.org
*   issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
* Server auth using Basic with user 'vagrant'
> POST /api/asciicasts HTTP/1.1
> Authorization: Basic <...hidden...>
> User-Agent: curl/7.29.0
> Host: asciinema.org
> Accept: */*
> Content-Length: 5658
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=----------------------------6ca3f3de6469

그렇다면 Python에서 사용하는 SSL lib가 curl과 다르고 문제가 SSL 영역 어딘가에 있습니까?

나도 그렇게 생각해. Python은 OpenSSL을 사용하고 curl은 NSS를 사용합니다.

@andyone ascii.kaos.io 의 인증서는 Let 's Encrypt가 아닙니다.

RapidSSL SHA256withRSA

일반적으로 CentOS에 Let 's Encrypt (또는 이와 유사한 😊)에 대한 루트 인증서가 누락되어 있지만 SSL 연결이 이루어지고 오류가 HTTP 프로토콜 수준 (400 Bad Request)에 있으므로 ... 👐

Let 's Encrypt의 루트 인증서가 없으면 curl에서도 작동하지 않습니다.

(Brightbox)로드 밸런서는 실제로 haproxy를 사용합니다. HTTP RFC 및 haproxy 문서는 헤더를 본문에서 분리하는 데 하나의 CRLF가 필요하다고 명시합니다.

https://github.com/haproxy/haproxy/blob/master/doc/internals/http-parsing.txt

여기에서 전체 CRLF가 아닌 CR 또는 LF 만 보낼 수 있습니까?

@sickill 이것은 LibreSSL 2.5.0- https: //ascii-ha.kaos.io를 사용 하는 HA-Proxy 1.7.5의 프록시 입니다. My 및 @ThiefMaster 녹음과 저장소의 over-4k.json 이이 프록시를 통해 성공적으로 업로드되었습니다.

@andyone 좋아요. 그렇다면 tune.bufsize (https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-tune.bufsize)를 4096으로 변경할 수 있습니까?

@johnl CRLF를 확인했고 여기에서 모두 괜찮습니다.

다시 CentOS와 macOS 모두에서 요청을 tcpdumped했습니다 (HTTP 페이로드가 HTTPS에 대해 동일하다고 가정하고 HTTP를 통해).

dump-centos.pcap.txt 및 dump-mac.pcap.txt에는 tcpdump 캡처 ( tcpdump -s 0 dst port 80 -w dump-centos.pcap.txt )가 포함되어 있습니다.
dump-centos-hex.txt 및 dump-mac-hex.txt에는 16 진 형식의 덤프가 포함됩니다 ( hexdump -C ).

dump-centos-hex.txt
dump-centos.pcap.txt
dump-mac-hex.txt
dump-mac.pcap.txt

두 OS 모두에서 새 줄에 사용되는 CRLF가 있고 헤더와 본문 사이에 하나의 빈 줄이 있습니다.

왼쪽 CentOS, 오른쪽 macOS :

@sickill 구성이 업데이트되었습니다. over-4k.json 업로드되었습니다.

@andyone 업데이트 주셔서 감사합니다. X-Forwarded-Proto 헤더를 추가하지 않은 것 같습니다 (반환 된 녹화 URL이 http:// 이므로). http-request set-header X-Forwarded-Proto https if { ssl_fc } 를 추가 할 수 있습니까?

이것은 내 구성입니다.

frontend www-https
    bind 207.154.241.251:443 ssl crt /etc/ssl/private/kaos.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    server asciinema-backend asciinema.org:80

이 줄을 어디에 추가해야합니까?

@andyone backend 섹션으로 이동해야한다고 생각합니다 (나는 haproxy 전문가가 아닙니다).

@andyone btw, 디버그를 도와 주셔서 정말 감사합니다 😍 감사합니다!

앞으로도 잊지 마세요. 이것은 SSL 암호를 사용하여 설정을 매우 밀접하게 복제해야합니다.

    tune.bufsize 4096
    tune.ssl.default-dh-param 2048
    tune.maxrewrite 40

frontend www-https
    bind 207.154.241.251:443 ssl no-sslv3 crt /etc/ssl/private/kaos.pem ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    server asciinema-backend asciinema.org:80
    mode http
    option forwardfor
    option httplog

나는 이것으로 구성을 수정했지만 운이 없다.

    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option                  http-server-close
    option                  forwardfor
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend www-https
    bind 207.154.241.251:443 ssl crt /etc/ssl/private/kaos.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    http-request set-header X-Forwarded-Proto https
    server asciinema-backend asciinema.org:80

클라이언트는 여전히 http:// 링크를 반환합니다.

유용한 서비스를 개선 할 수 있도록 항상 기꺼이 도와 드리겠습니다 😉.

@johnl 이것은 전체 구성이며 모든 필수 옵션은 defaults 및 global 섹션에서 설정됩니다.

    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    tune.bufsize 4096

    # SSL configuration
    tune.ssl.default-dh-param 2048
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option                  http-server-close
    option                  forwardfor
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend www-https
    bind 207.154.241.251:443 ssl crt /etc/ssl/private/kaos.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    http-request set-header X-Forwarded-Proto https
    server asciinema-backend asciinema.org:80

@andyone 의 haproxy 구성이 이제 BB에 매우 가깝고 여전히 문제를 재현 할 수없는 경우 https://ascii-ha.kaos.io 와 https://asciinema.org 의 차이점 중 하나입니다

이것은 https://ascii-ha.kaos.io 와 https://asciinema.org 의 차이점 중 하나입니다

아니요. BB LB는 OpenSSL로 구축 할 수 있습니다 (저는 LibreSSL을 사용합니다).

https://ascii-ha.kaos.io에 Let 's Encrypt 인증서를 추가해 보겠습니다

완료-https: //ascii.kaos.re
HA-Proxy 1.7.5 (LibreSSL 2.5.0 포함) + Let 's Encrypt 인증서 (Certbot에서 생성)
구성 :

    tune.bufsize 4096
    tune.ssl.default-dh-param 2048
    tune.maxrewrite 40

frontend www-https
    bind 207.154.241.251:443 ssl no-sslv3 crt /etc/ssl/private/ascii.kaos.re.pem ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    server asciinema-backend asciinema.org:80
    mode http
    option forwardfor
    option httplog

모든 것이 잘 작동하는 것 같습니다. over-4k.json 업로드되었습니다.

나는 이것에 대한 더 이상의 아이디어가 없습니다. 로드 밸런싱 및 SSL 종료를 위해 자체 Nginx 인스턴스로 롤백하는 것을 고려 중입니다 🤕

문제를 재현 할 수있는 단일 curl 명령으로이 문제를 해결하려고하지만 아직 관리하지 않았습니다. 누구든지 도울 수 있습니까?

curl을 사용하여 인증 사용자 이름 / 비밀번호로 5k 본문을 게시하고 있습니다. netcat 웹 서버 백엔드를 사용하여 Brightbox로드 밸런서를 사용하여 원시 요청 텍스트를 볼 수 있습니다. 항상 통과-잘못된 요청 응답을 트리거 할 수 없습니다.

이것이로드 밸런서에 의해 거부되는 경우 백엔드에 앱의 실제 인스턴스가 필요하지 않아야합니다. 그렇게 멀어지지 않아야하므로 앱없이 curl로이를 재현 할 수 있어야합니다.

나는 우분투와 centos7에서 그리고 특별히 openssl을 사용하여 curl을 시도했습니다 (사용할 sslib lib를 선택하기 위해 curl에 --engine 명령을 지정할 수 있습니다. centos7 curl 바이너리는 대부분의 옵션에 대해 빌드됩니다)

@johnl 이것을 조사해 주셔서 감사합니다.

테스트 용 백엔드로 netcat을 사용하는 것이 합리적입니다 👍

asciinema upload over-4k.json 해당하는 curl은 다음과 같습니다.

curl -v -X POST -u test:uuid4 https://asciinema.org/api/asciicasts -F [email protected]

( uuid4 를 python3 -c 'import uuid; print(uuid.uuid4())' 의 결과로 대체)

그리고 그것은 실제로 컬과 함께 작동합니다 ...

asciinema upload tcpdump와 위의 curl을 비교했는데 HTTP 프로토콜 수준에서 의심스러운 것은 없습니다. 그러나 일부 tcp 프레임은 다른 위치에 표시됩니다 (각 tcp 패킷에 더 많거나 적은 데이터가 전송 / 적합 될 수 있음).

CentOS 7 VM에서 tcpflow로 HTTP 요청 (http://asciinema.org로)을 캡처했습니다.

sudo tcpflow -p -C -i eth0 port 80 >tcpflow-req.txt

그런 다음 동일한 VM의 다른 셸에서 다음을 실행했습니다.

ASCIINEMA_API_URL=http://asciinema.org asciinema upload /vagrant/over-4k.json

응답을 끊고 요청 만 남겼습니다. 다음은 바이트 단위로 전송되는 내용입니다. tcpflow-req.txt

이 캡처 된 HTTP 요청을 asciinema에 대해 재생했습니다. org : 80 with nc :

bash-4.4$ (cat tcpflow-req.txt; cat) | nc asciinema.org 80
HTTP/1.1 201 Created
Server: nginx
Date: Mon, 12 Jun 2017 13:30:03 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 48
Connection: close
Status: 201 Created
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Location: http://asciinema.org/a/4lgbbik7li4ywzqrfak0e7eku
ETag: "9beb7ac6bb5981f06fdc71df3947d8b0"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 2a8a8c75-ed06-4741-9adb-e5d276032ded
X-Runtime: 0.360858
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15768000

http://asciinema.org/a/4lgbbik7li4ywzqrfak0e7eku

문제 없다.

이제 SSL을 통해 asciinema로 보냈습니다. org : 443 :

(cat tcpflow-req.txt; cat) | openssl s_client -connect asciinema.org:443

결과는 다음과 같습니다.

CONNECTED(00000003)
depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=asciinema.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFFDCCA/ygAwIBAgISBDhrp0YwV5NtleFOG+Zj61lQMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA2MDcwOTEyMDBaFw0x
NzA5MDUwOTEyMDBaMBgxFjAUBgNVBAMTDWFzY2lpbmVtYS5vcmcwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+/g237mVels4G9blsZlaeeiURbSp22eGO
T5OZ5As9NyuxSvRVEJrs4xk/RBEkCVgeZspSOmkRLwXG+FSMtjhbqIUt73AUKMdm
4DG+OwkVxjZatskL0wUWRcU7DmyW/Ls/OFJpPPcZ+pqu/v/ek99EiVNoAHJzXMXJ
ZsWy5KLE3fhkrlyMvdIkOkCK5zHOT95t0i8OmdaPIekPBa57VhvnDlUJsYyCF9GN
mP8Qg6OygexyULJGqBwiZ0BN2J6cYwChUlSvqFnkL4OzfixZ+mItuhl1b1vx/N5K
XMtPiM+nc/S+/liIWgtt7HIy9NmrOtSKbPTh3Bv/rfNdaiYx5CUHAgMBAAGjggIk
MIICIDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFNAMhQNNwl+/bJjml9hrrHYzBxbf
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wLwYDVR0RBCgwJoINYXNjaWluZW1hLm9yZ4IVc3RhZ2luZy5hc2NpaW5lbWEu
b3JnMIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAm
BggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUF
BwICMIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBv
biBieSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRo
IHRoZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5j
cnlwdC5vcmcvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBABxmJxdQQCcy
FpCkiDrB+vonBUCLYSJtrFkmRdmj9W8/ADpC6M/EhYFOCgrO2cmhYfy1SxDAP5Hd
KIhd3p1F931MMXVcxYt2n6FiDJHN531qp6eBzjZsVIgHXS27PAV466IIMTydNQSe
reyDc9fi+q+ji1Gz89nI8lHIOlRt3dzVGT2J3oQidsm4ZuPNJFj4y8MUrbUAOOH6
YY4n395OKV7vWzl7VPKiCWx+zsv4bzr6IGUPlwqCN2e6cppPWE47ugnYsarINCHO
ie5lU4E2N0k2qVWe/+uYbwSUQ0nrEx8R078m6+6EjDkR4VLboLjuV5tGBgHsJLQB
CmLH6CmNCRE=
-----END CERTIFICATE-----
subject=/CN=asciinema.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3436 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES128-SHA
    Session-ID: AC26CBF8D3719B1DE709A9A8AEAB43D20B14C62085A74604338C512CEA4472C5
    Session-ID-ctx:
    Master-Key: 0C59B1A2B6802D35FAD26DEE139043A853F3E62787E9AA743A8CAFDA95744DB73AB42B511F37EA7D6BB398A352938551
    Key-Arg   : None
    Start Time: 1497273777
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.0 400 Bad request
Cache-Control: no-cache
Connection: close
Content-Type: text/html

<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>

/ cc @johnl

@sickill https://ascii.kaos.re에서 동일한 요청을 확인할 수 있습니까

@andyone이 방금 확인했습니다. (cat tcpflow-req.txt; cat) | openssl s_client -connect ascii.kaos.re:443 성공적으로 업로드되었습니다.

나는 여기서 더 많은 것을 파헤 쳤다. centos7의 curl은 nss를 사용하지만 wget은 openssl을 사용합니다. curl 또는 wget을 사용하여 성공적으로 요청을 보낼 수 있습니다. python httpie 도구 (python 3 아래)를 사용하여 보낼 수도 있습니다.

하지만 stdin을 통해 openssl s_client로 보내는 데 실패합니다.

그러나 stdin을 사용하는 대신 요청을 붙여 넣어 openssl s_client로 전송하는 데 성공합니다!

나는 이것이 필요한 CRLF 라인 엔딩이 아닌 LF 라인 엔딩으로 요청을 보내고 있기 때문에 이것이 확실하다고 확신하지만, 무엇인지 잘 모르겠습니다. 나는 "openssl s_client"가 나쁜 테스트 도구이고 무슨 일이 일어나고 있는지 확인하기 어렵게 만든다고 생각합니다.

그러나 나는 아직 nss 또는 openssl을 사용하든 적절한 http 클라이언트로 이것을 재현하지 못했습니다 (우분투의 컬도 openssl을 사용하고 잘 작동하므로 두 번 확인했습니다). 다른 사람이 관리합니까?

방금 몇 가지 테스트를 수행했으며이 문제가 콘텐츠 길이 4520으로 지속되지만 동일한 요청이 1000 자 (변경 사항에 따라 조정 된 Content-Length 가 아니라는 것을 확인할 수 있습니다.

CRLF는 내 모든 테스트에 있으며 xxd 는 파이프를 통해 전송되었음을 확인합니다.
OpenBSD의 nc (TLS 지원)으로 테스트 할 수도 있습니다.

문서에서 :

tune.bufsize
버퍼 크기를이 크기 (바이트)로 설정합니다. 낮은 값은 더 많은 것을 허용합니다
세션이 같은 양의 RAM에 공존하고 값이 높을수록
매우 큰 쿠키가있는 응용 프로그램이 작동합니다. 기본값은 16384이며
빌드시 변경할 수 있습니다. 이것을 변경하지 않는 것이 좋습니다
매우 낮은 값은 다음과 같은 일부 서비스를 중단하므로 기본값에서
통계 및 기본 크기보다 큰 값은 메모리 사용량을 증가시킵니다.
시스템의 메모리가 부족할 수 있습니다. 최소한 글로벌 maxconn
매개 변수는이 값이 증가하는 것과 같은 요인으로 감소되어야합니다.
HTTP 요청이 (tune.bufsize-tune.maxrewrite)보다 크면 haproxy가
HTTP 400 (잘못된 요청) 오류를 반환합니다. 마찬가지로 HTTP 응답이 더 큰 경우
이 크기보다 haproxy는 HTTP 502 (잘못된 게이트웨이)를 반환합니다.

전체 요청을 메모리에 저장하지 않고 즉시 전달 (AFAIK)하거나 최소한 임시 파일로 버퍼링하는 nginx와는 달리.

이 no option http-buffer-request 옵션 , 이는 내가 행동이 정확히 그 권리를 비활성화 가지고있는 경우 (작성된 option http-buffer-request 하지 않고, no ) :

때때로 HTTP 요청의 본문을 기다리는 것이 바람직합니다.
결정을 내립니다. 이것은 "balance url_param"에 의해 수행되는 작업입니다.
예. 첫 번째 사용 사례는 이전에 느린 클라이언트의 요청을 버퍼링하는 것입니다.
서버에 연결. 또 다른 사용 사례는 라우팅을 취하는 것입니다.
요청 본문의 내용에 따라 결정. 이 옵션은
프론트 엔드 또는 백엔드는 HTTP 처리가 전체
본문이 수신되었거나 요청 버퍼가 가득 찼거나 첫 번째 청크가
청크 인코딩의 경우 완료됩니다. 원치 않는 부작용이있을 수 있습니다.
HTTP를 남용하는 일부 애플리케이션은
프런트 엔드와 백엔드가 사용되므로
기본.

나도 쳤어. HTTP를 통해 작동하지만 HTTPS가 아닌 동일한 콘텐츠를 테스트하면 클라이언트와 프록시 사이에 많은 추가 헤더가 추가되지 않는 한 버퍼 크기가 잘못 될 가능성이 낮습니다.

그러나 SSL 연결을 종료하는 버그가 헤더를 약간 손상시킬 수 있습니다.

그렇다면 HAProxy의 보안을 낮추지 만 덜 준수하는 HTTP 트래픽을 허용하는 옵션이 있습니다. https://stackoverflow.com/questions/39286346/extra-space-in-http-headers-gives-400-error-on-haproxy를 참조

최종 수정으로 보안 감소를 옹호하지는 않지만이를 통해 디버깅하는 동안 서비스를 유지할 수 있습니다.

나는 그들의 Haproxy의 설정을 제어하지 않도록 순간 asciinema.org에서 @peterbrittain는 Brightbox 클라우드 부하 분산 장치를 사용합니다. 우리는 우리 자신의 Nginx에서 SSL을 종료하는 데 사용되었으며 제대로 작동했습니다. BB LB로 전환했기 때문에이 문제가 발생합니다 (일부). CentOS 또는 다른 시스템에서 경험하고 있습니까?

솔직히, 이전 Nginx 기반 솔루션에 문제가 없었습니다. 우리가 가지고 있던 SSL 인증서가 만료되어 Let 's Encrypt로 갈 것이라고 생각했습니다. LE 인증서는 수명이 짧기 때문에 자동으로 관리하는 것이 가장 좋으며 Brightbox LB가이를 수행합니다. LE 설정 작업을 절약하고 싶었고 BB LB가 가장 간단한 솔루션 인 것처럼 보였습니다 (asciinema.org는 Brightbox가 후원하고 훌륭한 인프라에서 실행되기 때문입니다). 이제 Nginx에서 LE를 직접 설정하면이 문제를 해결하는 데 이미 소비 한 시간의 1/10이 걸릴 것이라고 생각합니다. 😞😞😞

아. 나는 누가 어떤 비트를 소유했는지에 대한 미묘함을 발견하지 못했습니다. 이 문제에 대해 BB에서 진단을받은 적이 있습니까?

그리고 귀하의 질문에 대한 대답 : 내 상자는 CentOS 6 VM입니다.

나는 또한 asciinema 1.2.0 (우분투 16.04 lts의 버전)을 사용하여 잘못된 요청 문제를 경험했습니다.

위에 주어진 컬 해킹이 작동했습니다.

방금 동일한 파일이 Gentoo [1] 상자에서 잘못된 요청을 생성하지만 OpenBSD [2] 상자에서는 그렇지 않다는 것을 방금 발견했습니다.
OpenBSD는 잘 업로드합니다.
이 클라이언트들 간의 차이점에 대한 추가 조사가 필요하다고 생각합니다.
젠투 박스는이 빌드 당 다음과 같은 파이썬 타겟을 지원합니다 :

PYTHON_TARGETS="python3_4 -python3_5"

나는 현재 python3.5를 쉽게 테스트 할 수 없지만 아마도 이것은 이미 도움이 될 것입니다.

편집 : OpenSSL 버전을 추가했지만 완전히 잊어 버렸습니다.

• asciinema 1.4.0
  
  
  
  • python-exec 2.4.5를 사용하여 실행
  
  
  • 차례로 Python 3.4.6 실행
  
  

• OpenSSL 1.0.2l 2017 년 5 월 25 일

• asciinema 1.3.0

  • Python 3.6.0을 사용하여 실행
• LibreSSL 2.5.2

방금 이전 구성으로 다시 전환했습니다 (Nginx에서 SSL 종료). 지금 작동하는지 알려주세요 @andyone @ThiefMaster @benaryorg @peterbrittain @ThomasWaldmann

@sickill 나는 그것이 이전에 실패한 동일한 파일이라고 85 % 확신하지만 만약 그렇다면, 당신은 그것을

@sickill 지금은 매력적으로 작동합니다. 👍

네, ( asciinema upload ) 나에게도 작동합니다. 감사!