How does Charles see domain when do not enable ssl proxying - ssl

When Charles do not enable ssl proxying, Charles still see the domain, but i can't see the domain when i check connection in Wireshark, Why? How does Charles do?

That's because the host (domain) is not encrypted in HTTPS protocol. It is delivered in plain text.
For Wireshark, actually you can intercept ClientHello packet and find the host in plain text there. Please refer to https://stackoverflow.com/a/38727920/707451

Related

How does an SSL-enabled Cloudflare proxy connect to a non-SSL endpoint?

new Cloudflare user here.
I have an A record, but I don't have the any cert installed on the server that I'm pointing to. I know you can proxy through CF and CF has free SSL set up on the proxy endpoint.
My question is: how does CF connect to my endpoint securely? Or am I understanding incorrectly?
My understanding:
me --[SSL-enabled]--> CF Proxy --[no SSL?]--> my server
The short answer is that CloudFlare doesn't connect to your endpoint securely through their free SSL certificate.
CloudFlare offers three types of SSL setups, with 'flexible' being the default:
Flexible: They'll serve content over HTTPS from their infrastructure, but the connection between them and the origin is unencrypted
Full: Still HTTPS from CloudFlare to the browser but they'll also talk HTTPS to the origin although they won't validate the certificate
Full (strict): CloudFlare issues the certificate and they'll intercept your traffic, but then it's all HTTPS to the origin and the cert is validated as well
While a flexible, free SSL certificate from CloudFlare will show your visitors a secure HTTPS padlock, this method of SSL only exists between CloudFlare and the ISP, not between CloudFlare and your server. The flexible certificate is shared between 50 different domains (revealing each of these to your visitors), though does indeed protect from common attacks such as WiFi snooping.
Flexible:
Full:
A Full certificate also encrypts traffic between CloudFlare and the origin, but CloudFlare doesn't validate the cert. A strict certificate remedies this.
If unsure on the quality of your SSL, I'd recommend checking out Qualys' SSL Labs test.
For more information see Troy Hunt's article on the issue.
how does CF connect to my endpoint securely?
Since you don't offer a secure connection to your endpoint Cloudflare cannot use a secure connection to your endpoint. This is, only the connection between the browser and Cloudflare is secure but not the final connection from Cloudflare to your server.
See also the description of the Flexible SSL option you are talking about which explicitly points of the problems:
Flexible SSL: A Secure connection between your visitor and Cloudflare, but no secure connection between Cloudflare and your web server. ... This option is not recommended if you have any sensitive information on your website. ...It should only be used as a last resort if you are not able to setup SSL on your own web server. ...

HAProxy - SSL SNI inconvenience

I found some inconvenience in haproxy 1.5 when i try to configure SSL SNI.
There is a fragment of haproxy configuration: pastebin
I would like to pass client IP to backend. No matter how I configure reqadd / set-header X-Forwarded-For / Real-IP I always got a haproxy IP address in X-Forwarded-For.
Someone try to pass real IP with SSL SNI on HAProxy
? :/
From this configuration, you seem to be doing SNI-sniffing, yet all of the backends are looping back to HAProxy itself... which is not a case where SNI-sniffing is required. Perhaps I'm overlooking something else that would require this.
It should be apparent why you are getting the proxy's IP in X-Forwarded-For -- HAProxy is talking to itself. The first pass through the proxy is the client connection, as far as the proxy can determine on the second pass, because only the second pass is speaking HTTP. It only sees that an incoming TCP connection has arrived... from itself.
The solution is for the first-pass backend to pass the original client information using the Proxy Protocol and the second-pass frontend to decode it.
Add accept-proxy to the bind lines for the second-pass frontends, and add send-proxy to the server lines on the first-pass backends. This way, on the connection where HAProxy is talking to itself, the first-pass backend will send the Proxy protocol preamble and the second-pass frontend will decode the incoming value and place it in X-Forwarded-For.

Stream with Wowza over SSL, Connection Refused or invalid response

I installed Wowza and is Streaming by this links:
HTTP:
http ://[my-ip]:1935/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
and also on
http ://[my-subdomain]:1935/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
When is config Wowza to be able to stream on port 80, it works again on these links:
http ://[my-ip]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
http ://[my-subdomain]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
but we must stream over SSL protocol.
means: HTTPS:
https ://[my-subdomain]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
We installed a wildcard SSL on our server and everything is working great. In general, port 1935 does not work over HTTPS! even when we add port 80 to Wowza, HTTPS connection is refused and we can't have streaming over https.
How can we stream over SSL on wowza? even with or without port 1935
Thanks
Yes, Wowza server supports streaming with SSL using StreamLock or your own SSL certificate.
You will need to set up a different port number for HTTPS. It could be that another process is using port 80. Port 443 is typically used.
From the Server tab, click Edit.
Click Add Host Port and fill in fields.
Check Enable SSL/StreamLock.
Save and re-start Wowza server.
Look in [install-dir]/logs/wowzastreamingengine_access.log for errors. It will give a clue as to whether there is a problem with the certificate, password or other.
I was recommend place a LB infront of my Wowza for SSL offloading so you can load the m3u8 over SSL. I was also told you can do that quite easily using HA Proxy for example. It is explained how to accomplish this here for RTMP but the same can obviously done with HTTP:
https://github.com/arut/nginx-rtmp-module/issues/457#issuecomment-250783255
Note, I have not tried this yet and I am unclear on exactly the proper use scenario. Nor, have I successfully enable StreamLock with my own cert nor the cert provided through Wowza. If I manage to do so I will update this thread. Hope this is helpful.

XirSys WebRTC secure connection

Setting up my simplewebrtc.html video chat room
Google Chrome browser decides http connections are no longer supported (https only)
I get my SSL certificate - and end up with this problem...
Mixed Content: The page at 'https://myURL.com/xsdk-master/examples/simplewebrtc.php?roomName=767' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://endpoint02.uswest.xirsys.com:8080/socket.io/1/?t=1450578074425'. This request has been blocked; the content must be served over HTTPS.
Seems self-explanatory I need to use a secure endpoint on XirSys end, but
I tried getting in touch with experts#xirsys.com - and they're out until December 28th, 2015. Anybody know if a secure endpoint exists? Please any and all help is appreciated!
You need to update the port on the endpoint to 443. The 8080 port you are using won't work on a secure page.
Regards,
Lee

how to provide tcp/ssl support on the same port

Le'ts say you open a tcp socket on port 80 to handle http request, and a ssl socket on port 443 to deal with https...how can some proxy provide access to both of them on the same port??
I found only this link but it wasn't very useful. Can you provide me an erlang example or suggest me some resources from which i can learn more on the topic?
Thanks in advance
how can some proxy provide access to both of them on the same port??
By implementing the HTTP CONNECT method, the (non-transparent) proxy may switch to providing a TCP tunnel over which a browser may, for example, access an HTTPS resource.
A rather sparse specification:
https://www.rfc-editor.org/rfc/rfc2616#section-9.9
As outlined in the link you provide, you will need to write your own custom server that sniffs the request and then redirects to the correct protocol accordingly.
As http://www.faqs.org/rfcs/rfc2818.html indicates, an HTTP session will start with an Initial Request Line (e.g. GET /), whereas a TLS session will start with a ClientHello (more on the TLS session on wikipedia)
There are lots of resources online about writing servers in Erlang, e.g. How to write a simple webserver in Erlang?
Incidentally your terminology is incorrect: http, https SSL and TLS are protocols, and all operate (over the web) using TCP sockets.