ไม่สามารถเชื่อมต่อกับ https บน ubuntu -“ ข้อผิดพลาดโปรโตคอล SSL ที่ไม่รู้จัก”


2

ฉันไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์เฉพาะผ่าน SSL จากเซิร์ฟเวอร์ Ubuntu ของเราได้ ในเครื่อง Mac ของฉันทำงานได้อย่างไม่มีที่ติ

ที่อยู่เซิร์ฟเวอร์: powerschool.spokaneschools.org

curl -v https://powerschool.spokaneschools.org เอาท์พุท:

  • สร้าง URL ใหม่เป็น: https://powerschool.spokaneschools.org/
  • ไม่พบชื่อโฮสต์ในแคช DNS
  • กำลังลอง 206.193.1.72 ...
  • เชื่อมต่อกับ powerschool.spokaneschools.org (206.193.1.72) พอร์ต 443 (# 0)
  • ตั้งค่าสถานที่ตรวจสอบใบรับรองเรียบร้อยแล้ว:
  • CAfile: none CApath: / etc / ssl / certs
  • SSLv3, การจับมือ TLS, สวัสดีลูกค้า (1):
  • ข้อผิดพลาดโปรโตคอล SSL ที่ไม่รู้จักในการเชื่อมต่อกับ powerschool.spokaneschools.org:443
  • การปิดการเชื่อมต่อ 0 curl: (35) ข้อผิดพลาดโปรโตคอล SSL ที่ไม่รู้จักในการเชื่อมต่อกับ powerschool.spokaneschools.org:443

openssl s_client -connect powerschool.spokaneschools.org:443 เอาท์พุท:

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1466726411
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

ฉันลองตรวจสอบไซต์ด้วยเครื่องมือตรวจสอบ SSL ที่แตกต่างกันดูเหมือนว่าทั้งหมดจะใช้ได้ (นอกเหนือจากปัญหาด้านความปลอดภัย) ฉันไม่มีปัญหาในการเชื่อมต่อกับเซิร์ฟเวอร์อื่น ๆ แม้แต่ในโดเมนนั้น

ระบบปฏิบัติการ

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:        14.04
Codename:       trusty

$ curl -V
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 

$ openssl version -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon May  2 16:53:18 UTC 2016
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

ทำงานได้ดีสำหรับฉัน ลองใช้ตัวเลือก "-k" บน curl หรือโปรดระบุรุ่น distro และรุ่น curl ("curl -V") เพื่อให้เราสามารถเข้าใจปัญหาได้ดีขึ้น
jehad

1
@jehad เพิ่มข้อมูลเพิ่มเติมเพิ่มแล้ว -k ไม่มีผล คุณจัดการเพื่อรันบน Ubuntu หรือไม่?
Kuf

ฉันใช้ซอฟต์แวร์รุ่นเดียวกันกับคุณ (เซิร์ฟเวอร์ Ubuntu 14.04.4, กำลังใช้ curl 7.35.0, openssl 1.0.1f) และฉันก็ลองใช้เครื่องเดสก์ท็อปส่วนตัวที่ใช้ LinuxMint 17.3 อยู่ คอมโพเนนต์ curl / openssl เดียวกัน) เซิร์ฟเวอร์ ubuntu ของฉันทำงานใน virtualbox VM ดังนั้นฉันคิดว่ามันอาจลงมาที่โครงสร้างพื้นฐานของคุณ ... เซิร์ฟเวอร์ของคุณทำงานอะไรมันคือโฮสต์คลาวด์หรือเครื่องท้องถิ่น และมีไฟร์วอลล์หรือพร็อกซีหรือไม่ และเป็นการทดสอบทางวิทยาศาสตร์คุณลองทดสอบการอ้างอิง (เช่น "superuser.com:443" หรือ "google.com:443") หรือไม่
jehad

@jehad ไม่มีพร็อกซีไฟร์วอลล์มีข้อยกเว้นที่ถูกต้อง (AWS VPC) และการเชื่อมต่อ SSL กับเซิร์ฟเวอร์อื่นทั้งหมดใช้งานได้แม้กระทั่งเซิร์ฟเวอร์อื่นในโดเมนนั้น
Kuf

เป็นการยากที่จะพูดว่าจะทำอย่างไรต่อไปเนื่องจากทุกสิ่งชี้ไปที่ปัญหาในสภาพแวดล้อมเฉพาะของคุณ ถ้าเซิร์ฟเวอร์สาธารณะทั้งหมดเข้าถึงได้ แต่ไม่ใช่เซิร์ฟเวอร์นี้ดูเหมือนว่าจะต้องมีการพิมพ์ผิดในกลุ่มความปลอดภัย AWS ของคุณ คุณรู้วิธีการ tcpdump และ wireshark หรือไม่? อ่านคำตอบของ Steffen Ullrich ด้านล่างเขาถูกต้องในการวิเคราะห์ของเขาและ tcpdump อาจช่วยยืนยัน การทดลองขั้นพื้นฐานอื่น ๆ ... 1) ลองใช้ VM / VPC อื่น (บนแล็ปท็อปในเครื่องของคุณหรือใน AWS) 2) อาจฟังดูงี่เง่า แต่ลืมขดคุณเคยลอง ping พื้นฐาน ("ping powerschool.spokaneschools.org") ไหม
jehad

คำตอบ:


1

มันใช้งานได้สำหรับฉันและมันควรจะทำงานกับ curl / openssl เวอร์ชันของคุณด้วย errno 104 หมายถึงการรีเซ็ตการเชื่อมต่อดังนั้นฉันจึงคิดว่าบางมิดบ็อกซ์เช่นไฟร์วอลล์เป็นสาเหตุของปัญหา ตรวจสอบจากเครือข่ายอื่นที่คุณมั่นใจได้ว่าไม่มีไฟร์วอลล์ที่เกี่ยวข้อง


ฉันไม่คิดว่านี่เป็นปัญหาไฟร์วอลล์ - ฉันสามารถเชื่อมต่อกับเซิร์ฟเวอร์เดียวกันโดยไม่ใช้ SSL และฉันสามารถเชื่อมต่อกับเซิร์ฟเวอร์อื่นในโดเมนนั้นได้ แต่ไม่ใช่กับเซิร์ฟเวอร์นั้น หากเป็นปัญหาไฟร์วอลล์ฉันคาดว่าการโทรไปยังโดเมนนั้นทั้งหมดจะล้มเหลว
Kuf

@Kuf: ขึ้นอยู่กับไฟร์วอลล์ หากเป็นไฟร์วอลล์การตรวจสอบที่ลึกจะตรวจสอบเป้าหมายการเชื่อมต่อภายในข้อความ TLS ClientHello และปิดกั้นหากไม่ชอบ เนื่องจากมันใช้งานได้สำหรับฉันกับ openssl รุ่นเดียวกันบนระบบปฏิบัติการเดียวกันและที่อยู่ IP เป้าหมายเดียวกันและเนื่องจากการเชื่อมต่อ TCP พื้นฐานทำงานได้ แต่เซิร์ฟเวอร์ (หรือไฟร์วอลล์) ตั้งค่าการเชื่อมต่อใหม่จึงต้องเป็นปัญหาในเครือข่ายของคุณ - หรือเซิร์ฟเวอร์บล็อก คุณ.
Steffen Ullrich

เซิร์ฟเวอร์อยู่ใน amazon VPC และ 'ไฟร์วอลล์' เท่านั้นที่เราใช้คือกลุ่มความปลอดภัยซึ่งอนุญาตให้ส่งผ่านพอร์ต 443 ทั้งหมด
Kuf

@Kuf: "SSL handshake อ่าน 0 ไบต์และเขียน 0 ไบต์" - ดูเหมือนว่าการรีเซ็ตเกิดขึ้นก่อนที่จะส่ง ClientHello ดังนั้นจึงเป็นบล็อกที่ระดับ TCP - ทั้งที่ไฟร์วอลล์ของคุณหรือไฟร์วอลล์อื่น ๆ ที่หน้าเซิร์ฟเวอร์ .
Steffen Ullrich

เนื่องจากมันใช้งานได้สำหรับคุณ แต่ไม่ใช่สำหรับฉันมันปลอดภัยหรือไม่ที่จะสมมติว่าปัญหาเกิดขึ้นในเซิร์ฟเวอร์ของฉัน
Kuf
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.