search

alumae / kaldi-gstreamer-server

Real-time full-duplex speech recognition server, based on the Kaldi toolkit and the GStreamer framwork.
BSD 2-Clause "Simplified" License
1.07k stars 341 forks source link

added SSL support for server #60

Closed yifan closed 7 years ago

yifan commented 7 years ago

With this change, the server will listen to port and port+1 if --certfile and --keyfile are used. Normal ws:// connection should use port port, secured websocket wss:// will use port port+1. This will get around the problem Chrome prevents user to send audio data to non-secure server.

Usage: master_server.py --certfile=fullchain.pem --keyfile=privkey.pem

alumae commented 7 years ago

Don't you think it would be cleaner if the master only listens on one port, using either ws:// or wss:// (wss would be turned on if the certfile and keyfile arguments would be given)?

ngoel17 commented 7 years ago

Just curious if this has been tested with chrome and found to work

On Thu, Nov 24, 2016, 2:58 AM Tanel Alumäe notifications@github.com wrote:

Don't you think it would be cleaner if the master only listens on one port, using either ws:// or wss:// (wss would be turned on if the certfile and keyfile arguments would be given)?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alumae/kaldi-gstreamer-server/pull/60#issuecomment-262712495, or mute the thread https://github.com/notifications/unsubscribe-auth/AIZyeAXEm8IMyJrdIycDi8titdyNcOfAks5rBUOzgaJpZM4K6y-b .

alumae commented 7 years ago

BTW, I just use nginx as a proxy to convert wss to ws, works with Chrome.

yifan commented 7 years ago

I was using one single port for ws:// or wss:// depending on command line option before. Then I didn't want to change my worker scripts, so I thought this works best to have compatibility of existing setup. It is true nginx will work just fine. This is just another option. Tested on Chrome and Edge.

alumae commented 7 years ago

I decided to go with the solution that I described: the server now uses SSL on the specified port if the keyfile and certfile options are specified. I committed the changes to master, largely based on this PR. @yifan, I hope this won't break your applications when you update your local repos, as I didn't use this port+1 method proposed by you.

yifan commented 7 years ago

@alumae the problem with that solution is when you have local worker node trying to connect with wss://localhost, I am not sure how the certificate works, since it is verified with a certain domain name. Maybe it doesn't matter.

alumae commented 7 years ago

I tested it and it worked for me (used a valid certificate for a outwards domain name, worker connected to localhost).