I'm trying to see if it's possible to do an SSL handshake through cloud code. So far all I have found is https://parse.com/questions/is-it-possible-to-attach-a-certificate-to-httprequest
But I was hoping to get a more clear answer regarding whether this is possible or not.
Related
I try to read the website https://www.eroids.com/reviews with Indy and always get a 403.
This website seems only to load when I set the ssl version to sslvTLSv1_1. If I do that, this website loads fine, but other websites not. Most other seems to use sslvTLSv1_2.
As long I only add [sslvTLSv1_1] to the sslversion, it works, but when I add [sslvTLSv1_1, sslvTLSv1_2], the mentioned site does not load anymore (again 403), but any other site does.
My question is: How can I determine what sslversion a website need? Do I need to try to access the site with each ssl version until I get a 200 back or is there something to me unknown integrated into indy to automatically do that?
How can I determine what sslversion a website need?
In general, you can't. However, most servers support version negotiation during the TLS handshake, so that clients supporting multiple/different TLS versions can negotiate with the server for which TLS version to use. But, it sounds like maybe this particular server does not support that.
However, the fact that you are even getting an HTTP 403 response at all for an HTTPS url means a TLS session is being created fine, so the issue is something else.
Unless the server is ignoring all TLS errors during the handshake and creating a simple TLS session, THEN is sending an HTTP error in reply to an earlier TLS error. Which is rare, but not unheard of.
Do I need to try to access the site with each ssl version until I get a 200 back
In this particular situation, probably so, yes. Start with [sslvTLSv1_1, sslvTLSv1_2], and if that fails then retry with [sslvTLSv1_2], then retry with [sslvTLSv1_1], and so on.
is there something to me unknown integrated into indy to automatically do that?
Indy does not have that capability at this time, no.
I have set up lighttpd with mod_websocket as discussed in Dom Bramley's blog entry (except that I am using a BeagleBone Black with Debian Wheezy instead of an rPi.)
https://www.ibm.com/developerworks/community/blogs/B-Fool/entry/setting_up_an_mqtt_websocket_gateway_for_raspberry_pi?lang=en
[During the lighttpd/mod_websocket build process I was asked if I wanted to patch the server and I said yes.]
I have the mosquito MQTT broker running on the same host and publishing on various topics.
When I try to connect to the broker with a browser client via the web socket, I can see that everything works okay in terms of the http upgrade to websocket and forwarding the connection request to mosquitto. Mosquitto gets the connection request and accepts it. However, the response that gets back to the browser does not include the Sec-Websocket-Protocol header echoing the subproto specifier mqttv3.1 that was in the original upgrade request. The client correctly rejects this answer and the connection is shut down.
The javascript error from mqttws31.js:912 is "Sent non-empty Sec-Websocket-Protocol header but no response is received." With Wireshark, I can see that this is true; the 101 Switching Protocols response has headers Upgrade, Connection, and Sec-Websocket-Accept, but nothing else.
My mod_websocket config file defines host, port, type, and subproto the same as Dom's example, and I can see from various debug statements that the request gets all the way to Mosquitto correctly.
Can anyone suggest how to get the Websocket-Protocol header to be included in the response? It must work, Dom wrote a blog post describing how he did it!
I think recent versions of mod_websocket broke/removed subprotocol support, but can't confirm it right now. You could try an earlier version, or use a dedicated websocket to tcp gateway like WSS
https://github.com/stylpen/WSS/
The mod_websocket author (Norio Kobota) quickly and effectively resolved this issue for me by making an update to mod_websocket. The fix is currently in a development branch, and available on github. Our discussion is part of the thread for mod_websocket issue 28.
Briefly, the use case that I have (pre-written client library and existing TCP backend) is much less flexible than a roll-your-own client and server combination with respect to connect-time protocol negotiation. However, in my case I don't really need any flexibility or negotiation with the backend, and so mod_websocket can just echo the configuration it has been given without having to dive into the details of the subprotocol.
The updated mod_websocket echoes the subproto entry from its config file during websocket handshake which satisfies the MQTT client library.
So now I have two solutions for adapters between websocket clients and TCP backends! Thanks all for your help.
Doug Johnson
Is the data secure if posted programmatically (not through a browser) to an https endpoint?
My understanding is browser encrypts data and sends it to https endpoint. How can a Ruby or Node.js or any other program do the same?
Yes. If you connect to an https endpoint with curl, wget, or whatever library, the transfer is secure from the source of the connection to the destination. That source could be a server (your webserver) or the client browser.
However, if it's done in client side JS or other browser scripting language, you have to make sure the initial request from client to your site is secure as well if first passing secure data to the client for it to pass to the destination https server.
I checked node.js request library as well as Ruby HTTParty libraries. Both these support SSL encryption based on proper options (port: 443 etc.). In general if we use any well supported library that enables HTTP gets and posts, we should be covered in terms of transmitting data securely to the https endpoint.
I think I understand what you mean and that question has been answered. However, I would just point out that HTTPS does not make your data secure, only the connection and even that is only encrypted from eavesdropping which is not really secure.
There is, of course, lots more to think about and do to make your data secure end-to-end.
I'm trying to write a server for a webSocket connection. I've read the spec (76, not 75) carefully. I'm using minefield as the browser.
When I try to create a WebSocket from javascript in the browser:
var ws = new WebSocket("ws://localhost:8766/hoho");
The browser responds with
"Firefox can't establish a connection to the server at ws://localhost:8766/hoho."
My server is getting a valid client handshake request, it sends back the response and then boom.
I've run every example handshake example I can find through my server and I match the given responses exactly in every instance. I'm pretty confident that the return byte stream is correct. I don't need help debugging my code, it's doing what I mean it to do. I need help debugging my use of the handshake protocol since when I give minefield what I think is a correct response it laughs at me.
My question is this: How can I debug this thing? I can think of two possibilities.
Is there any way to get minefield to tell me WHY it's rejecting my handshake?
Is there a working, public, webSocket server service on the web? If there is, I can proxy it, watch the byte streams in both direction and figure out where mine is different.
Does anyone have any ideas in these directions or any other ideas?
Thanks for any help.
I'm in the process of debugging a similar situation, and the tool I'm relying on most is netcat, with some additional use of openssl. Shut down your websocket server and run nc -l 8766. That lets you record exactly what headers are being sent. Turn the websocket server back on and use nc 8766 to paste in those same headers and see the result. openssl s_client -connect localhost:443 will let you make the request with ssl, if that is in your mix.
From there, make sure the responses conform completely to the websocket handshake protocol. For instance, my problem right now is that my responses have Connection: close, which is no good.
About the 2nd possibility.
Yes, there is a websocket server out there.
the jWebSocket demo server at http://jwebsocket.org/demos/chat/chat.htm
hope this helps
Added: Echo socket server at: http://www.websocket.org/echo.html
Here's a jsfiddle that I made from http://www.websocket.org echo websocket server which works in Chrome but not in Firefox 6: http://jsfiddle.net/awDLc/
It is adjusted to use MozWebSocket rather than WebSocket, but perhaps that isn't enough?
I understand from various sources that the HTTPS handshake is the heaviest part of using HTTPS. I'm using POSTs internally between my servers to communicate information and would like to use HTTPS for it. I wondered how long the actual HTTPS handshake lasts/"stays open"? Is it re-done for each POST I'm sending to a server, or what is the lifetime?
The SSL handshake is only done at the beginning of a session and is mainly about generating a shared session key that is used to encrypt all later traffic.
You can find a very good description of the handshake here.
I believe the handshake occurs on connection (ie, as part of the SSL negotiation). It you use HTTP keep-alive connections then the handshake only occurs once as long as the connection is active.
I don't know the particulars, but I'm sure the handshake is supposed to occur only when the session is started. It would be too expensive otherwise.
Edit: Here's a nice description of the process.