saqura / xmppwb

XMPP Webhook Bridge [Archived]
MIT License
73 stars 8 forks source link

Add option to ignore SSL certificates on the webhooks #3

Closed jeremyrichardmann closed 8 years ago

jeremyrichardmann commented 8 years ago

New issue to add an Unsafe option, to allow bypass of SSL validation.

I have the code working with a -u option on the command line, just need permission to push a branch so you can merge.

saqura commented 8 years ago

Thanks for your interest in contributing! The general workflow to contribute changes on github is to fork the project, push the changes to your own fork, and then create a pull request using the github UI.

only issue I have now is it not trusting SSL certificate for the rocket.chat server, though it does have a valid cert

Can you post the exact error you get (using the -d and -v flags for verbose debugging)? Currently the default python SSL context is used, which uses the system's default CA certificates. Maybe python cannot find the default certificates. The issue might also be that your server is using an old SSL version that is not supported (SSLv2 and SSLv3, which are deprecated).

Instead of bypassing SSL validation I would rather add an option to specify the path to the server certificate though since that should work in case Python cannot validate it using the default certificates or in case of self-signed certificates.

jeremyrichardmann commented 8 years ago

Looks like that did it, adding the trusted roots to /etc/pki/ca-trust/source/anchors and running update-ca-trust worked (Centos7)

From: saqura [mailto:notifications@github.com] Sent: Wednesday, March 02, 2016 1:56 PM To: saqura/xmppwb Cc: Mann, Jeremy Subject: Re: [xmppwb] Add option to ignore SSL certificates on the webhooks (#3)

Thanks for your interest in contributing! The general workflow to contribute changes on github is to fork the project, push the changes to your own fork, and then create a pull request using the github UI.

only issue I have now is it not trusting SSL certificate for the rocket.chat server, though it does have a valid cert

Can you post the exact error you get (using the -d and -v flags for verbose debugging)? Currently the default python SSL contexthttps://urldefense.proofpoint.com/v2/url?u=https-3A__docs.python.org_3_library_ssl.html-23ssl.create-5Fdefault-5Fcontext&d=CwMCaQ&c=qhent5lL-8Lans1hhN7NTGhSd0GBLfQfwUvzHj1D5tQ&r=vISVQJ8QhUeiifah2LNan7Cj4y9rpzli7Pm0SYgjb_I&m=zrP_3SLS9X-fNT9i5SU_B5Uy2C0Td0DJjAbwJDJcNlA&s=t9xKjhDeUO74punV4zUD_4kmHWjLgjCqUR9wYKpTNO8&e= is used, which uses the system's default CA certificateshttps://urldefense.proofpoint.com/v2/url?u=https-3A__docs.python.org_3_library_ssl.html-23ssl.SSLContext.load-5Fdefault-5Fcerts&d=CwMCaQ&c=qhent5lL-8Lans1hhN7NTGhSd0GBLfQfwUvzHj1D5tQ&r=vISVQJ8QhUeiifah2LNan7Cj4y9rpzli7Pm0SYgjb_I&m=zrP_3SLS9X-fNT9i5SU_B5Uy2C0Td0DJjAbwJDJcNlA&s=CImjVu_J1EoSQ1TB8zWYRMlBZhODzmeAw_fZeSJ8PZI&e=. Maybe python cannot find the default certificates. The issue might also be that your server is using an old SSL version that is not supported (SSLv2 and SSLv3, which are deprecated).

Instead of bypassing SSL validation I would rather add an option to specify the path to the server certificate though since that should work in case Python cannot validate it using the default certificates or in case of self-signed certificates.

— Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_saqura_xmppwb_issues_3-23issuecomment-2D191399316&d=CwMCaQ&c=qhent5lL-8Lans1hhN7NTGhSd0GBLfQfwUvzHj1D5tQ&r=vISVQJ8QhUeiifah2LNan7Cj4y9rpzli7Pm0SYgjb_I&m=zrP_3SLS9X-fNT9i5SU_B5Uy2C0Td0DJjAbwJDJcNlA&s=I4FrUiiCrerL44Y7LkN5LKxTE96v0To0IPVZgBU0AIc&e=.

This message contains confidential information and is intended only for the named individual. If you are not the named individual you are strictly prohibited from disseminating, distributing, or copying this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. The sender expressly reserves all privileges and confidentiality which might otherwise be waived as a result of an erroneous or misdirected transmission. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. No employee or agent is authorized to conclude any binding agreement on behalf of Scott & White Healthcare or any affiliated entity with another party by email without express written confirmation by the CEO or the Vice President of Supply Chain Services. Scott & White Healthcare www.sw.org

saqura commented 8 years ago

Great that this fixed it. I think this is a better solution than not verifying the certificate at all.

saqura commented 8 years ago

There is now a cafile option to explicitely specify the certificate chain used for validating the outgoing webhook server.