New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOS - Change Language - crash due to untrusted SSL certificate #184

Closed
ghost opened this Issue May 5, 2018 · 47 comments

Comments

Projects
None yet
3 participants
@ghost

ghost commented May 5, 2018

Hello,
I changed the language from English to German.
After a restart of syncplay the following error occurs:
error

can I change the language back manually in a file or something else?

OS: MacOS High Sierra 10.13.4
syncplay: last (1.5.3a)

edit:
deleting and reinstall of syncplay do not change anything

@Et0h

This comment has been minimized.

Contributor

Et0h commented May 6, 2018

I don't know how it works on macOS, but on other platforms you can resolve this by either (a) running the client with the --language en commandline switch as per https://syncplay.pl/guide/client/ or (b) delete the .syncplay file in the %HOME% folder (or in Windows the Syncplay.ini file in the %APPDATA% folder). Not sure why German didn't work in the first place though - was there any more debug information?

@ghost

This comment has been minimized.

ghost commented May 6, 2018

ahh nice, thanks...
i have found an hidden file in my User-Folder :-)
/Users/****/.syncplay

i have changed the language back to en. Now it works :-)

hm i have found this in the apple-console: May 6 18:26:17 ****-iMac com.apple.xpc.launchd[1] (pl.syncplay.Syncplay.17036[2757]): Service exited with abnormal code: 255

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 7, 2018

Ok, I tried to reproduce this on my High Sierra and Sierra machines, so far with no luck. I need further information.

  • does the crash happen before loading the configuration dialog or before actually running syncplay?
  • what player and which version are you using?
  • when you selected German and ran syncplay for the first time, did the player start or did the app crash? Were you able to see Syncplay interface in German even once?
  • did you alter the settings in any other way besides selecting German? (e.g. username or room name)
  • are you able to reproduce the issue now? (if you select German again, does the app still crash?)

In case you are able to reproduce the crash, it would be great if you could post here a python traceback. To get it, you need to run Syncplay from a terminal. Navigate to the path of Syncplay.app (usually /Applications/Syncplay.app/) and then in Contents/MacOS (so usually, run cd /Applications/Syncplay.app/Contents/MacOS/. Then run Syncplay by executing ./Syncplay. Any error message should now cause a traceback log in the terminal window from which you ran Syncplay. Please paste the error message here.

Thanks for your assistance.

@ghost

This comment has been minimized.

ghost commented May 8, 2018

Hey,

  • Syncplay went well for a week. (English)
  • VLC 3.0.1
  • If I select German and then click on "store configuration and run syncplay" I see syncplay in German and VLC starts. The crash comes at the next start of syncplay.
  • nope. I only changed the language.
  • yes. I only changed the language and it crash on the next start.
    If it helps: italiano works, but RU not...

Traceback (most recent call last): File "/Applications/Syncplay.app/Contents/Resources/__boot__.py", line 98, in <module> _run() File "/Applications/Syncplay.app/Contents/Resources/__boot__.py", line 82, in _run exec(compile(source, path, 'exec'), globals(), globals()) File "/Applications/Syncplay.app/Contents/Resources/syncplayClient.py", line 19, in <module> SyncplayClientManager().run() File "syncplay/clientManager.pyc", line 7, in run File "syncplay/ui/ConfigurationGetter.pyc", line 491, in getConfiguration File "syncplay/ui/ConfigurationGetter.pyc", line 412, in _forceGuiPrompt File "syncplay/ui/ConfigurationGetter.pyc", line 376, in _promptForMissingArguments File "syncplay/ui/GuiConfiguration.pyc", line 27, in run File "syncplay/ui/GuiConfiguration.pyc", line 1343, in __init__ File "syncplay/ui/GuiConfiguration.pyc", line 1226, in populateEmptyServerList File "syncplay/ui/GuiConfiguration.pyc", line 345, in updateServerList UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 21: ordinal not in range(128) 2018-05-08 06:31:51.515 syncplay[5565:2425123] Syncplay Error

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 8, 2018

Thanks, I found and fixed the bug, but many questions arise:

  • Why was the client unable to retrieve the list of public servers? Are you using a firewall to block Syncplay?
  • Why did the Syncplay app crash after that traceback? The client is supposed to attempt sending the message and continue, which is what happened during my tests. The client never crashed. I suppose there is at least another bug that is triggering a "Syncplay Error" in the last line, but I am afraid that until we push a release with the first fix, you will not see a more detailed error message about the crash.

albertosottile added a commit to albertosottile/syncplay that referenced this issue May 8, 2018

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 8, 2018

Actually, I found a way to move this further. @Shakal1710 could you please download and install Syncplay from my bintray account? This is the .dmg that contains the fix mentioned above (plus a lot of other new stuff that hopefully will not interfere with this bug). After you installed the updated app, run it from Terminal again and see if you can still reproduce the crash. If so, post here the (hopefully updated) error log. Thanks again.

@ghost

This comment has been minimized.

ghost commented May 8, 2018

hey,

  • I don't know why the client was unable to retrieve the list of public servers :-(
    I did not block anything in my firewall (MacOS Firewall is off and my router firewall is not configured either)... don't know....
  • the "crash" is the terminate button in the dialog window... (see first post)

the new version is working good! German language is now active :-)
no error message.

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 8, 2018

Great! What happens if you push the "Liste aktualisieren" button in the configuration dialog while Syncplay is set in German?

@ghost

This comment has been minimized.

ghost commented May 8, 2018

there comes the message "Konnte die Liste der öffentlichen Server nicht laden. Bitte besuche http://www.syncplay.pl/ [Englisch] mit deinem Browser."

can I ping the server where the list is located?
can that be problematic with my port forwarding? which port uses this function?

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 8, 2018

Well, at the moment I am glad that the error message shows correctly as designed. I will investigate how the server list is updated as soon as I have some spare time. Thanks for your assistance in reproducing this bug.

@ghost

This comment has been minimized.

ghost commented May 8, 2018

no problem :)

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 8, 2018

The update server function loads a URL with several (optional?) parameters: https://syncplay.pl/listpublicservers. This base url should load even with no parameters (afaik). Please check if you can load this URL in your browser.

@Et0h apparently we forgot to edit the "failed-to-load-server-list-error" message and update the url with https:// in all languages. Though this is only a cosmetic issue, I will add a commit to PR #185 about this. I will also add a commit that fixes this unicode bug.

@ghost

This comment has been minimized.

ghost commented May 8, 2018

yes, I can load this page

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 8, 2018

Then something happens in the utils.getListOfPublicServers() function, but you cannot see any error message about it because it is correctly masked by the IOError exception, which triggers the error dialog that you are seeing now. I am not an expert about exceptions in python but, as far as I know, there is no way to skip the exception and get the error message without running Syncplay from its sources and edit the malfunctioning part.

I am still unable to reproduce this part of the issue, given that updating the server lists works for me on High Sierra. If anyone has any suggestions about how to debug this server list retrieval issue on @Shakal1710 machine, please step forward.

albertosottile added a commit to albertosottile/syncplay that referenced this issue May 9, 2018

@Et0h

This comment has been minimized.

Contributor

Et0h commented May 9, 2018

@albertosottile I think we could make it check if it is in --debug mode and if so to run the 'raise' command to show the normal stack trace.

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 10, 2018

@Et0h How should I check if Syncplay is in --debug mode? constants.DEBUG_MODE apparently is updated only when the configuration dialog is closed. I checked and it is always False before the main window starts.

@Et0h

This comment has been minimized.

Contributor

Et0h commented May 11, 2018

@albertosottile I think you could add the constants.DEBUG_MODE = config['debug'] to GuiConfiguration.py.

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 11, 2018

@Shakal1710 I just pushed a fix that shows the update-server-error traceback log when Syncplay is in debug mode. Can you please download and install again Syncplay from my bintray (link)?
Then execute it from Terminal, but this time in debug mode, by running

cd /Applications/Syncplay.app/Contents/MacOS/
./Syncplay --debug

Then try again to update the servers. This time a traceback should appear in the Terminal window. Please, paste it here. Thanks again for your assistance.

@ghost

This comment has been minimized.

ghost commented May 12, 2018

Traceback (most recent call last): File "syncplay/utils.pyc", line 380, in getListOfPublicServers File "urllib.pyc", line 87, in urlopen File "urllib.pyc", line 213, in open File "urllib.pyc", line 443, in open_https File "httplib.pyc", line 1053, in endheaders File "httplib.pyc", line 897, in _send_output File "httplib.pyc", line 859, in send File "httplib.pyc", line 1278, in connect File "ssl.pyc", line 353, in wrap_socket File "ssl.pyc", line 601, in __init__ File "ssl.pyc", line 830, in do_handshake IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

The "error window" shows "socket error"

@daniel-123

This comment has been minimized.

Contributor

daniel-123 commented May 12, 2018

When we recently switched entire website to https I have made its SSL configuration very strict. I'm completely unfamiliar with how cert stores and so on work on OSX, but such errors usually mean that there is a mismatch between what precisely is required by SSL server (in this case it is the syncplay.pl web server) and supported in SSL client (ssl.py within syncplay). Technically the certificate itself could be all wrong, but given that it works everywhere else I'd dismiss that option.

I don't know if syncplay on OSX uses operating system framework for SSL, but if it doesn't is it possible that somehow you have old version of openssl or python? Or for some reason it doesn't trust letsencrypt signed certificates?

@ghost

This comment has been minimized.

ghost commented May 12, 2018

then I typed quit

quit
HTTP/1.1 400 Bad Request
Server: nginx/1.10.3
Date: Sat, 12 May 2018 20:57:11 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
read:errno=0
@daniel-123

This comment has been minimized.

Contributor

daniel-123 commented May 12, 2018

Hmm, that would make the issue fairly clear. Result of the command confirms that for some reason default openssl implementation used on OSX doesn't have "DST Root CA X3" in its CA store and that this is separate CA store from what the browser uses. This means that not a single letsencrypt certificate will be trusted by python programs on Mac.

As to why @albertosottile doesn't reproduce it - perhaps you have your own, more current openssl (or just certificates) version installed through homebrew? This would explain it working for you. Can you confirm whether it is the same on a default Mac which doesn't have all the dev tools installed?

All that said - there is still one big hole in this hypothesis. How in the world does this break only if you select German language? This would imply different certificates trusted depending on language settings, which seems utterly insane to me, but I cannot test it as I don't have a Mac. Could either of you test result of the openssl test from before with different operating system language settigns?

@daniel-123 daniel-123 self-assigned this May 12, 2018

@daniel-123 daniel-123 changed the title from MacOS - Change Language - crash to MacOS - Change Language - crash due to untrusted SSL certificate May 12, 2018

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 13, 2018

@daniel-123 homebrew openssl by default is keg-only, so it does not overwrite macOS default version. However, I do not think that our bundled .dmg uses system-wide openssl libraries since those are quite old. As a confirmation, here there are the results of the commands you asked, ran on my macOS 10.12 laptop (sorry, but is the only one I have available for the next two weeks).

which openssl
/usr/bin/openssl
openssl version
OpenSSL 0.9.8zh 14 Jan 2016
openssl s_client -showcerts -connect syncplay.pl:443 -strict -servername syncplay.pl
unknown option -strict

Given that the bundle includes a libssl and a libcrypto, I am quite convinced that Syncplay uses its own ssl libraries. But, for some reason, they are not working on @Shakal1710 machine.

@Shakal1710 Your openssl version string looks quite weird, perhaps you installed a different version of openssl in your system somehow. Can you post the result of which openssl here? Also, knowing your full $PATH by running echo $PATH could be nice. Thanks.

@ghost

This comment has been minimized.

ghost commented May 13, 2018

hey, I have not changed anything on the system...

the "retrieve the list of public servers" failure is available in all languages

Philips-iMac:~ philip$ which openssl
/usr/bin/openssl
Philips-iMac:~ philip$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin

@ghost ghost closed this May 13, 2018

@ghost ghost reopened this May 13, 2018

@ghost

This comment has been minimized.

ghost commented May 13, 2018

I'll try it on a MacBook Pro early 2015 with clean install. (I wanted to sell it anyway)

edit:
new install of High Sierra (10.13.4) on my MacBook Pro:
Same open ssl Version (LibreSSL 2.2.7)
and same problem with loading the public serverlist

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 13, 2018

Then I will have to check the output of openssl version in my 10.13.4 setup, but unfortunately that will not be possible for the next two weeks :/ I tested server list retrieval and it worked, though. If anyone else with that macOS version can test updating server list and post the results of those commands before, that would be great.

Edit: Apple switched to LibreSSL in HIgh Sierra, so that string is probably normal.

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 24, 2018

@Shakal1710 Sorry if I disappeared, now I am back. Can you please download an updated version of Syncplay from my bintray (link), install it, run it again in debug mode as described before, and attempt to update the server list? Please paste here the error message, if any. Once again, thanks for your help.

@ghost

This comment has been minimized.

ghost commented May 25, 2018

Ok, I will test it later this day :)

@ghost

This comment has been minimized.

ghost commented May 26, 2018

sorry for late answer :(

at the start:
Traceback (most recent call last): File "syncplay/utils.pyc", line 380, in getListOfPublicServers File "urllib.pyc", line 87, in urlopen File "urllib.pyc", line 213, in open File "urllib.pyc", line 443, in open_https File "httplib.pyc", line 1053, in endheaders File "httplib.pyc", line 897, in _send_output File "httplib.pyc", line 859, in send File "httplib.pyc", line 1278, in connect File "ssl.pyc", line 353, in wrap_socket File "ssl.pyc", line 601, in __init__ File "ssl.pyc", line 830, in do_handshake IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

update public list:
Traceback (most recent call last): File "syncplay/utils.pyc", line 380, in getListOfPublicServers File "urllib.pyc", line 87, in urlopen File "urllib.pyc", line 213, in open File "urllib.pyc", line 443, in open_https File "httplib.pyc", line 1053, in endheaders File "httplib.pyc", line 897, in _send_output File "httplib.pyc", line 859, in send File "httplib.pyc", line 1278, in connect File "ssl.pyc", line 353, in wrap_socket File "ssl.pyc", line 601, in __init__ File "ssl.pyc", line 830, in do_handshake IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

@daniel-123

This comment has been minimized.

Contributor

daniel-123 commented May 26, 2018

The traceback still strongly points to SSL outside Syncplay being the direct culprit. This is further supported by previous result of openssl s_client -showcerts -connect syncplay.pl:443 -servername syncplay.pl command, which has the line verify error:num=20:unable to get local issuer certificate in it - as I previously mentioned this means that openssl didn't find the DST Root CA X3 root certificate in the cert store it is using.

There are still some things that aren't clear to me:

  • Initially this issue was occurring only with German language. @Shakal1710 @albertosottile: Can you confirm this on your Macs? Additionally - does this issue occur for just German or for any language that isn't English?
  • Do you use the same language/locale at OS level? Does changing it have any impact?
  • Are certs signed with DST Root CA X3 only ones affected? @Shakal1710 could you test the command openssl s_client -showcerts -connect syncplay.pl:443 -servername syncplay.pl for different domains? github.com, google.com and letsencrypt.org for example.

As far as understanding and remedying the issue goes, it depends on why exactly that root cert is missing:

  • If changing language in Mac results in using python cert store which lacks DST Root CA X3 - then it is a bug to be filed at Apple. Letsencrypt also should be notified as their compatibility list doesn't mention this issue, they also have far more weight to throw around at Apple to fix their shit (if it is actually broken).
  • If not using that root cert is "works as designed", then there are few other options we could consider (none of them really good): bundle our own cert store with needed root certificate, use a different vendor to get our certificate (which implies recurring fees) or provide an unencrypted fallback when accessing server list.
  • I think it is almost impossible that the cause of this behaviour is within Syncplay code itself. It might be the case that for some inexplicable reason the cert store on @Shakal1710 machine got corrupt? It would be nice to test the openssl s_client -showcerts -connect syncplay.pl:443 -servername syncplay.pl command on a fresh installation of MacOS.
@ghost

This comment has been minimized.

ghost commented May 26, 2018

Its in all languages!!
changing region and language in MacOS from German to USA/english dosn't help

openssl s_client -showcerts -connect github.com:443 -servername github.com
CONNECTED(00000006)
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=5157550/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
-----BEGIN CERTIFICATE-----
MIIHQjCCBiqgAwIBAgIQCgYwQn9bvO1pVzllk7ZFHzANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE4MDUwODAwMDAwMFoXDTIwMDYwMzEy
MDAwMFowgccxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF
Ewc1MTU3NTUwMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG
A1UEBxMNU2FuIEZyYW5jaXNjbzEVMBMGA1UEChMMR2l0SHViLCBJbmMuMRMwEQYD
VQQDEwpnaXRodWIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
xjyq8jyXDDrBTyitcnB90865tWBzpHSbindG/XqYQkzFMBlXmqkzC+FdTRBYyneZ
w5Pz+XWQvL+74JW6LsWNc2EF0xCEqLOJuC9zjPAqbr7uroNLghGxYf13YdqbG5oj
/4x+ogEG3dF/U5YIwVr658DKyESMV6eoYV9mDVfTuJastkqcwero+5ZAKfYVMLUE
sMwFtoTDJFmVf6JlkOWwsxp1WcQ/MRQK1cyqOoUFUgYylgdh3yeCDPeF22Ax8AlQ
xbcaI+GwfQL1FB7Jy+h+KjME9lE/UpgV6Qt2R1xNSmvFCBWu+NFX6epwFP/JRbkM
fLz0beYFUvmMgLtwVpEPSwIDAQABo4IDeTCCA3UwHwYDVR0jBBgwFoAUPdNQpdag
re7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFMnCU2FmnV+rJfQmzQ84mqhJ6kipMCUG
A1UdEQQeMByCCmdpdGh1Yi5jb22CDnd3dy5naXRodWIuY29tMA4GA1UdDwEB/wQE
AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0
oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcy
LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2Vy
dmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEF
BQcBAQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBS
BggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAA
MIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgCkuQmQtBhYFIe7E6LMZ3AKPDWY
BPkb37jjd80OyA3cEAAAAWNBYm0KAAAEAwBHMEUCIQDRZp38cTWsWH2GdBpe/uPT
Wnsu/m4BEC2+dIcvSykZYgIgCP5gGv6yzaazxBK2NwGdmmyuEFNSg2pARbMJlUFg
U5UAdgBWFAaaL9fC7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAWNBYm0tAAAE
AwBHMEUCIQCi7omUvYLm0b2LobtEeRAYnlIo7n6JxbYdrtYdmPUWJQIgVgw1AZ51
vK9ENinBg22FPxb82TvNDO05T17hxXRC2IYAdgC72d+8H4pxtZOUI5eqkntHOFeV
CqtS6BqQlmQ2jh7RhQAAAWNBYm3fAAAEAwBHMEUCIQChzdTKUU2N+XcqcK0OJYrN
8EYynloVxho4yPk6Dq3EPgIgdNH5u8rC3UcslQV4B9o0a0w204omDREGKTVuEpxG
eOQwDQYJKoZIhvcNAQELBQADggEBAHAPWpanWOW/ip2oJ5grAH8mqQfaunuCVE+v
ac+88lkDK/LVdFgl2B6kIHZiYClzKtfczG93hWvKbST4NRNHP9LiaQqdNC17e5vN
HnXVUGw+yxyjMLGqkgepOnZ2Rb14kcTOGp4i5AuJuuaMwXmCo7jUwPwfLe1NUlVB
Kqg6LK0Hcq4K0sZnxE8HFxiZ92WpV2AVWjRMEc/2z2shNoDvxvFUYyY1Oe67xINk
myQKc+ygSBZzyLnXSFVWmHr3u5dcaaQGGAR42v6Ydr4iL38Hd4dOiBma+FXsXBIq
WUjbST4VXmdaol7uzFMojA4zkxQDZAvF5XgJlAFadfySna/teik=
-----END CERTIFICATE-----
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
-----BEGIN CERTIFICATE-----
MIIEtjCCA56gAwIBAgIQDHmpRLCMEZUgkmFf4msdgzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowdTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTE0MDIGA1UEAxMrRGlnaUNlcnQgU0hBMiBFeHRlbmRlZCBW
YWxpZGF0aW9uIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBANdTpARR+JmmFkhLZyeqk0nQOe0MsLAAh/FnKIaFjI5j2ryxQDji0/XspQUY
uD0+xZkXMuwYjPrxDKZkIYXLBxA0sFKIKx9om9KxjxKws9LniB8f7zh3VFNfgHk/
LhqqqB5LKw2rt2O5Nbd9FLxZS99RStKh4gzikIKHaq7q12TWmFXo/a8aUGxUvBHy
/Urynbt/DvTVvo4WiRJV2MBxNO723C3sxIclho3YIeSwTQyJ3DkmF93215SF2AQh
cJ1vb/9cuhnhRctWVyh+HA1BV6q3uCe7seT6Ku8hI3UarS2bhjWMnHe1c63YlC3k
8wyd7sFOYn4XwHGeLN7x+RAoGTMCAwEAAaOCAUkwggFFMBIGA1UdEwEB/wQIMAYB
Af8CAQAwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRp
Z2ljZXJ0LmNvbTBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsNC5kaWdpY2Vy
dC5jb20vRGlnaUNlcnRIaWdoQXNzdXJhbmNlRVZSb290Q0EuY3JsMD0GA1UdIAQ2
MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMB0GA1UdDgQWBBQ901Cl1qCt7vNKYApl0yHU+PjWDzAfBgNVHSMEGDAW
gBSxPsNpA/i/RwHUmCYaCALvY2QrwzANBgkqhkiG9w0BAQsFAAOCAQEAnbbQkIbh
hgLtxaDwNBx0wY12zIYKqPBKikLWP8ipTa18CK3mtlC4ohpNiAexKSHc59rGPCHg
4xFJcKx6HQGkyhE6V6t9VypAdP3THYUYUN9XR3WhfVUgLkc3UHKMf4Ib0mKPLQNa
2sPIoc4sUqIAY+tzunHISScjl2SFnjgOrWNoPLpSgVh5oywM395t6zHyuqB8bPEs
1OG9d4Q3A84ytciagRpKkk47RpqF/oOi+Z6Mo8wNXrM9zwR4jxQUezKcxwCmXMS1
oVWNWlZopCJwqjyBcdmdqEU79OX2olHdx3ti6G8MdOu42vi/hw15UJGQmxg7kVkn
8TUoE6smftX3eg==
-----END CERTIFICATE-----
---
Server certificate
subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=5157550/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3586 bytes and written 463 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 74031E351C70265590DF92E73A00F4C200BDE6863EB3E4078773A63CD3D1FD18
    Session-ID-ctx: 
    Master-Key: 5B3555AAFE830EDE26952ABC3B77D10A3D90E8C0281A43FC40C89AB8BE0A39798A6D4DA2BC805805BA1F4923CF74EB59
    Start Time: 1527337097
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
openssl s_client -showcerts -connect google.com:443 -servername google.com
CONNECTED(00000005)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIHjzCCBnegAwIBAgIIPSbWenFyjugwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODA1MDgxNDMzNDBaFw0x
ODA3MzExMzI3MDBaMGYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgTExDMRUw
EwYDVQQDDAwqLmdvb2dsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASB
anXIrmgTYROnCkZRD/HHtKWkILug0lz8p0YZ508wKXjXY0iGYj71OWu01bpxD4ja
zSzCWAQZCUoZjIkb/RaIo4IFHDCCBRgwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDgYD
VR0PAQH/BAQDAgeAMIID4QYDVR0RBIID2DCCA9SCDCouZ29vZ2xlLmNvbYINKi5h
bmRyb2lkLmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29n
bGUuY29tghQqLmRiODMzOTUzLmdvb2dsZS5jboIGKi5nLmNvgg4qLmdjcC5ndnQy
LmNvbYIWKi5nb29nbGUtYW5hbHl0aWNzLmNvbYILKi5nb29nbGUuY2GCCyouZ29v
Z2xlLmNsgg4qLmdvb2dsZS5jby5pboIOKi5nb29nbGUuY28uanCCDiouZ29vZ2xl
LmNvLnVrgg8qLmdvb2dsZS5jb20uYXKCDyouZ29vZ2xlLmNvbS5hdYIPKi5nb29n
bGUuY29tLmJygg8qLmdvb2dsZS5jb20uY2+CDyouZ29vZ2xlLmNvbS5teIIPKi5n
b29nbGUuY29tLnRygg8qLmdvb2dsZS5jb20udm6CCyouZ29vZ2xlLmRlggsqLmdv
b2dsZS5lc4ILKi5nb29nbGUuZnKCCyouZ29vZ2xlLmh1ggsqLmdvb2dsZS5pdIIL
Ki5nb29nbGUubmyCCyouZ29vZ2xlLnBsggsqLmdvb2dsZS5wdIISKi5nb29nbGVh
ZGFwaXMuY29tgg8qLmdvb2dsZWFwaXMuY26CFCouZ29vZ2xlY29tbWVyY2UuY29t
ghEqLmdvb2dsZXZpZGVvLmNvbYIMKi5nc3RhdGljLmNugg0qLmdzdGF0aWMuY29t
ggoqLmd2dDEuY29tggoqLmd2dDIuY29tghQqLm1ldHJpYy5nc3RhdGljLmNvbYIM
Ki51cmNoaW4uY29tghAqLnVybC5nb29nbGUuY29tghYqLnlvdXR1YmUtbm9jb29r
aWUuY29tgg0qLnlvdXR1YmUuY29tghYqLnlvdXR1YmVlZHVjYXRpb24uY29tggcq
Lnl0LmJlggsqLnl0aW1nLmNvbYIaYW5kcm9pZC5jbGllbnRzLmdvb2dsZS5jb22C
C2FuZHJvaWQuY29tghtkZXZlbG9wZXIuYW5kcm9pZC5nb29nbGUuY26CHGRldmVs
b3BlcnMuYW5kcm9pZC5nb29nbGUuY26CBGcuY2+CBmdvby5nbIIUZ29vZ2xlLWFu
YWx5dGljcy5jb22CCmdvb2dsZS5jb22CEmdvb2dsZWNvbW1lcmNlLmNvbYIYc291
cmNlLmFuZHJvaWQuZ29vZ2xlLmNuggp1cmNoaW4uY29tggp3d3cuZ29vLmdsggh5
b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29tggV5dC5i
ZTBoBggrBgEFBQcBAQRcMFowLQYIKwYBBQUHMAKGIWh0dHA6Ly9wa2kuZ29vZy9n
c3IyL0dUU0dJQUczLmNydDApBggrBgEFBQcwAYYdaHR0cDovL29jc3AucGtpLmdv
b2cvR1RTR0lBRzMwHQYDVR0OBBYEFJymp5VhMPz21aT+YwDvvHIB1n1vMAwGA1Ud
EwEB/wQCMAAwHwYDVR0jBBgwFoAUd8K4UJpndnaxLcKG0IOgfqZ+ukswIQYDVR0g
BBowGDAMBgorBgEEAdZ5AgUDMAgGBmeBDAECAjAxBgNVHR8EKjAoMCagJKAihiBo
dHRwOi8vY3JsLnBraS5nb29nL0dUU0dJQUczLmNybDANBgkqhkiG9w0BAQsFAAOC
AQEAbmJINhswMQo1CdZKWriXVv3Fi/mgBcqxrwqFI5ujvIaBYeIN+eUi4RWzrIsh
rfQqIzNqXNMW+Jmk/odD3YEdNzI0xMuuDO0OKVU2RGwViY5M1i1ljFhJV/eGh3dQ
85nKLoGaAg0mVSAqD9w0bekp3aBEzXT/q4srtMq/bGGgkJaJ3cUmMBGe6xluF6Ne
MgVJojFxZJ6qvrOza2q34QhcRLVPsdP9lzQgwjnUBDBoKrKuOMresJEV3mJ5n5BB
0txxwL+/hKsyW0prYip4WGtZlUpu0q1Nuw6iHEbnUgmYcoBRu8R3bkVBgV92gYj1
ujt99TYBRRtrGZSc9VU3+ExamQ==
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
---
SSL handshake has read 3581 bytes and written 463 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES128-GCM-SHA256
    Session-ID: 04F38452630127BDAF7D9F5855A28A04BCA1615C53A66125A55A9CAAB8483B49
    Session-ID-ctx: 
    Master-Key: 1EEEA99B351BEEFFECD69707630AA5C06D2AD36D0F30DD61525660638700A913E2DAFB7F039796B66D9F1A1D2F138148
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 00 5f 58 ef 73 f3 23 f6-a0 04 94 8b d2 16 da b9   ._X.s.#.........
    0010 - ce eb f7 a0 99 85 c3 31-80 17 a0 8e 71 a8 8c 80   .......1....q...
    0020 - 78 91 51 94 b8 ca 3c e5-a3 5b 53 47 12 c9 56 7e   x.Q...<..[SG..V~
    0030 - 80 03 24 5c be 7b bf 11-ee 9a 4b b6 6b f4 e4 ae   ..$\.{....K.k...
    0040 - fa 37 6a 6f ea ac ee cb-a4 00 a7 f3 12 3d 58 3d   .7jo.........=X=
    0050 - 9d 81 fd 6e 0e a6 ae 77-1b 11 25 99 f5 dc d1 4f   ...n...w..%....O
    0060 - e6 3f 57 4c 97 57 d8 a2-9d 10 2c 28 f9 73 f0 58   .?WL.W....,(.s.X
    0070 - d9 ba 98 f8 c8 58 d7 d9-bb 56 c9 b5 ee 22 f2 21   .....X...V...".!
    0080 - 8b da 96 92 2e 5b 3b fe-34 8a a3 ef 18 8e 1d 65   .....[;.4......e
    0090 - 3c 64 96 28 ee ca 3f 79-11 f9 6d fe 27 48 91 58   <d.(..?y..m.'H.X
    00a0 - f5 04 9a a4 55 be 3d 3e-e4 0a 81 7d f1 57 99 4a   ....U.=>...}.W.J
    00b0 - cc 06 3c a5 74 d5 8c 2d-8c fe c6 69 7f df c1 08   ..<.t..-...i....
    00c0 - 7e e3 1d 2d 05 a8 6b 04-24 22 7f f4 41 6d 99 d3   ~..-..k.$"..Am..
    00d0 - 31 a3 71 9c 7e                                    1.q.~

    Start Time: 1527337196
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
openssl s_client -showcerts -connect letsencrypt.org:443 -servername letsencrypt.org
CONNECTED(00000005)
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=www.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIG3jCCBcagAwIBAgISA8aqqo3m80iS4ufG3lxSRSc0MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAzMDkxNzUxMDdaFw0x
ODA2MDcxNzUxMDdaMB4xHDAaBgNVBAMTE3d3dy5sZXRzZW5jcnlwdC5vcmcwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCiRkethDt2lCRyZP86hnGNWzyu
gw+evt6HIpHSbYxoopsG+zYT3Hs7bvAeJ16eTK9GtegLOgt23KrisrRYDjH2a+0o
uC2nKNhtDtKZZ6kLWoikeKevwdvz3fyB8WXvDegYmRfYcO4nF8HtgxHs/CBSk+GN
D/1MBrKtpFPRRgtZ9HIzw27MHPWSCIRP085BssOnIsPeSKmkIpiRUlnpcpddlmmR
I/LDiVfh3S1e/DDXg+E65PZ32mkBwblSzYW3ZuGLobxZScGra6Ntn7pIDMT0OYOr
7BekD5XT7tEU+vLaNdX9Myc25D7gO6ucNbl+PVimkJZVnfRJUyV6l3E4/lE/AgMB
AAGjggPoMIID5DAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFDplbXydu6+iBVsGO+SJ
2NSdXibpMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUF
BwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZy8wggHxBgNVHREEggHoMIIB5IIbY2VydC5pbnQteDEubGV0c2VuY3J5
cHQub3JnghtjZXJ0LmludC14Mi5sZXRzZW5jcnlwdC5vcmeCG2NlcnQuaW50LXgz
LmxldHNlbmNyeXB0Lm9yZ4IbY2VydC5pbnQteDQubGV0c2VuY3J5cHQub3Jnghxj
ZXJ0LnJvb3QteDEubGV0c2VuY3J5cHQub3Jngh9jZXJ0LnN0YWdpbmcteDEubGV0
c2VuY3J5cHQub3Jngh9jZXJ0LnN0Zy1pbnQteDEubGV0c2VuY3J5cHQub3JngiBj
ZXJ0LnN0Zy1yb290LXgxLmxldHNlbmNyeXB0Lm9yZ4ISY3AubGV0c2VuY3J5cHQu
b3JnghpjcC5yb290LXgxLmxldHNlbmNyeXB0Lm9yZ4ITY3BzLmxldHNlbmNyeXB0
Lm9yZ4IbY3BzLnJvb3QteDEubGV0c2VuY3J5cHQub3Jnghtjcmwucm9vdC14MS5s
ZXRzZW5jcnlwdC5vcmeCD2xldHNlbmNyeXB0Lm9yZ4IWb3JpZ2luLmxldHNlbmNy
eXB0Lm9yZ4IXb3JpZ2luMi5sZXRzZW5jcnlwdC5vcmeCFnN0YXR1cy5sZXRzZW5j
cnlwdC5vcmeCE3d3dy5sZXRzZW5jcnlwdC5vcmcwgf4GA1UdIASB9jCB8zAIBgZn
gQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsGAQUFBwIBFhpodHRwOi8vY3Bz
LmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIwgZ4MgZtUaGlzIENlcnRpZmlj
YXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IFJlbHlpbmcgUGFydGllcyBh
bmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIENlcnRpZmljYXRlIFBvbGlj
eSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0Lm9yZy9yZXBvc2l0b3J5LzAN
BgkqhkiG9w0BAQsFAAOCAQEAA2XC/7Dlt8KTXcob7KYeLyIR7pQUEYHJ7UQ/aykW
U5lepdXhwO6E/lj8nDQ0YlXY7EkHe857XUBIGwVXnXgopMqBB3uU1H0wotlgNWkd
GhPeq0HGGmtXV9WdHWRsmf10oce3SXpvDAwScY7oLjtgAf/jzLjjWf0DkHfuoeVW
KpvPkehj0bmHB2KOecMFcR5MMdKpCQd5BGabCEuCqgHhJXpFE7PrwbHNJQXnthAC
N0qZuHL1CrfKGrQXa29IJWjAqM7/43A+yUxIOMqgrWIbRhP7vpUjgN3NEpqqQVWa
ZwAH0b8c4xEM1luG5FrcPBBX+6y1M8VxVZUBeB4AGHGbQw==
-----END CERTIFICATE-----
 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
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=www.letsencrypt.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3613 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 1B6E53DA2273D9549BD8494229468B2C4248CB72710AFD7E158D42B8612DB2DB
    Session-ID-ctx: 
    Master-Key: 5E20EA21B8318D3A2FD74AFF58476D17D5B850F707C234FB6D6E6E4B9CA227C18921142E922D079FFBFFEFA442AE9793
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 00 00 0c e0 f4 30 43 06-91 90 6b 57 61 32 a0 a0   .....0C...kWa2..
    0010 - 78 da fe c6 80 cc 3e 41-d9 fc 7e 13 18 f8 01 f8   x.....>A..~.....
    0020 - ca 6d 8e 8e 1d e5 4b 8f-78 c2 48 06 5c d7 96 ea   .m....K.x.H.\...
    0030 - ef ff 2e ae f9 55 70 aa-77 b8 a3 d3 39 32 fb 69   .....Up.w...92.i
    0040 - 59 6e 1a 0a f0 08 79 4d-e0 6a 5c 62 58 75 bc 08   Yn....yM.j\bXu..
    0050 - a0 29 1d 73 03 ed 5b ec-aa 86 ba 76 1b 94 89 49   .).s..[....v...I
    0060 - ea 4b c5 c4 1b 88 a6 d2-b5 40 53 c8 5f 57 c2 db   .K.......@S._W..
    0070 - 48 64 55 c6 9b 43 42 49-56 55 11 0b a5 b6 be 60   HdU..CBIVU.....`
    0080 - ed 09 f1 09 f0 bc 48 9d-ae 30 a5 9f 6b d5 db b1   ......H..0..k...
    0090 - 30 ff ea 80 40 d9 38 c6-62 9e 29 40 4d a5 cf 03   0...@.8.b.)@M...
    00a0 - 1e 83 8f 2b ee 6b fa 32-91 ed 47 20 27 4e d3 02   ...+.k.2..G 'N..

    Start Time: 1527337337
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

its also broken on the Mac from my girlfriend. its also corrupt? hmmm

@daniel-123

This comment has been minimized.

Contributor

daniel-123 commented May 26, 2018

Okay, output of those commands says that openssl doesn't trust any of those three certificates. I'd like to assume that this is the default behavior (since you have 2 machines on which this works the same way) - but then this means that the openssl cert store provided by Apple is completely broken (or outright missing). Though in that light it is weird how:

  • English language in Syncplay somehow prevents this from occurring (I'll investigate how and why it behaves when encountering untrusted certificate)
  • Somehow It does work for @albertosottile
@albertosottile

This comment has been minimized.

Member

albertosottile commented May 26, 2018

EDIT: I am digging in the py2app bundle, even though we are embedding all crypto libraries, the bundler does not embed a copy of bin/openssl and uses the one that is available on the system. So, @daniel-123 you were right, I am sorry. Thus, we need to fix the server configuration to make it work with system openssl on vanilla macOS without homebrew. At this moment, from 10.12.6 for example, I get this:

~ alberto$ openssl version
OpenSSL 0.9.8zh 14 Jan 2016
~ alberto$ openssl s_client -showcerts -connect syncplay.pl:443 -servername syncplay.pl
CONNECTED(00000003)
28437:error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.7/src/ssl/s23_clnt.c:593:

Trying to find more info on this issue online I found this: requests/requests#2955 (comment)
Which certificate are we currently serving on syncplay.pl?

@daniel-123

This comment has been minimized.

Contributor

daniel-123 commented May 26, 2018

@albertosottile you can see the certificate within browser when visiting syncplay.pl website or put it through SSL Labs Test. SSL configuration on webserver is indeed incompatible with OpenSSL 0.9.8zh, as that is positively ancient version with no support for modern encryption (it doesn't even get to the point where it checks whether the certificate is valid). I'll investigate whether it is possible to configure SSL in a way that is both working with 0.9.8zh and not vulnerable to any of the known exploits (otherwise - http fallback is just as good).

That said - your protocol mismatch is completely different issue from what @Shakal1710 is seeing. His OpenSSL implementation is actually compatible with what the webserver is set to. It is just that it considers the certificate itself to be invalid - but given that it also thinks Google and Github certificates are untrusted I cannot really imagine how his OpenSSL (LibreSSL 2.2.7) is working correctly. I also don't understand why it is different from yours.

Edit: I've took a look at the requests issue you linked - it describes a site that doesn't serve intermediate cert. syncplay.pl does serve the expected intermediate cert - you can see it results of sample ssl connections all over this thread - there always are 2 blocks containing certificates: one for leaf and one for intermediate certs.

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 26, 2018

@daniel-123 The error log I reported before is relative to macOS 10.12, while those reported by @Shakal1710 refer to macOS 10.13, which embeds LibreSSL 2.2.7. On my 10.13 test machine, I get exactly the same results as him, yet the update function works because Syncplay is able to fallback on the homebrew openssl binary.

As far as I know, a viable and quicker solution for both systems could be to switch this getListOfPublicServers function from urllib to Requests. As a mere example, the code of the try part of the function could be replaced by:

import requests, syncplay, sys, messages
params = {'version': syncplay.version, 'milestone': syncplay.milestone, 'release_number': syncplay.release_number, 'language': messages.messages["CURRENT"]}
resp = requests.post(constants.SYNCPLAY_PUBLIC_SERVER_LIST_URL, data=params)
response = resp.text
response = response.replace("<p>","").replace("</p>","").replace("<br />","").replace("&#8220;","'").replace("&#8221;","'").replace(":&#8217;","'").replace("&#8217;","'").replace("&#8242;","'").replace("\n","").replace("\r","") # Fix Wordpress
response = ast.literal_eval(response)

Just tried this code on my macOS 10.13 machine using system python (not homebrew) and got

>>> response
[[u'syncplay.pl:8995 (France)', u'syncplay.pl:8995'], [u'syncplay.pl:8996 (France)', u'syncplay.pl:8996'], [u'syncplay.pl:8997 (France)', u'syncplay.pl:8997'], [u'syncplay.pl:8998 (France)', u'syncplay.pl:8998'], [u'syncplay.pl:8999 (France)', u'syncplay.pl:8999']]

while

>>> import ssl
>>> ssl.OPENSSL_VERSION
'LibreSSL 2.2.7'

So, in theory, this modification should work on vanilla macOS 10.13 installations. @daniel-123 Do you think this code is fine enough to put it in a Syncplay .dmg and make it test to @Shakal1710 ?

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 28, 2018

Ok so, apparently embedding Requests with py2exe is a nightmare and, after all, urllib seems to work on Windows so far. Thus, I see no reason to mess with code that works and I restricted the use and packaging of Requests to macOS only. @Shakal1710 can you please, once again, download and install the latest build from my bintray (link) and test it again as before? Hope this is the right one.

@ghost

This comment has been minimized.

ghost commented May 28, 2018

now its working!!! :-)
now I see the 5 servers in the list

I can not post anything because there are no errors in the terminal window :-)

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 28, 2018

@Shakal1710 Can you also verify that manually checking for updates works? Open Syncplay, store the configuration and run it, then from the menu bar go to the 'Help' menu and click 'Check for update'. No need to run Syncplay in debug mode. Thanks.

@daniel-123

This comment has been minimized.

Contributor

daniel-123 commented May 28, 2018

@albertosottile a small update as I've done some digging into how SSL in python is handled on OSX. Or rather - how by default there literally is no cert store so it simply will not work without additional steps. Requests apparently bundles its own cert store, which explains why it works.

In the end the missing piece that should be relatively easiest to integrate seems to actually be Certifi. I'm not sure if anything more than simply packaging it along with Syncplay is needed (as I don't have a clue how .dmg files work).

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 28, 2018

Certifi is already embedded with Requests. I tried to embed only Certify but it did not was enough for example for macOS 10.12, in which the default OpenSSL version is too old to support the profile of syncplay.pl. With Requests, everything works without homebrew on macOS 10.11+ .

@ghost

This comment has been minimized.

ghost commented May 29, 2018

@albertosottile the manual update check says there is a newer version available. than I can visit the website

@albertosottile

This comment has been minimized.

Member

albertosottile commented May 29, 2018

Ok, disregard the message about a newer version, I just wanted to check if your system could contact the server also in that function (if you want the correct message 'Syncplay is up to date' you can always download the latest build from my bintray, but that is not necessary). So, this issue appears to be fixed now, thanks for your assistance. I included the fix in the PR #185 , I will close this issue after the merge.

albertosottile added a commit to albertosottile/syncplay that referenced this issue May 30, 2018

@Et0h

This comment has been minimized.

Contributor

Et0h commented Jun 9, 2018

Thanks to everyone for your work in helping to fix this issue.

@Et0h Et0h closed this Jun 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment