I'm running a Node.js server for my college final year project. It's running on my local machine and I'm accessing it via the machine's private IP address. The application needs to record a short snippet of audio and send it back to the server, which will then send back a result based on the content of the audio file. Because the browser needs access to the microphone, it has to be HTTPS, even though I am not dealing with any sensitive information or even opening it to the internet. I just need to show it working at a demonstration, which I can do on a local network.
After hours of trial and error I managed to modify my current application to use HTTPS using a self signed certificate as described here. I can now access the web page over HTTPS (albeit with a huge red "This page is not actually secure" warning that I have to accept first) and chrome will grant me access to the microphone. However, when I click the button that sends a post request with the audio, chrome gives me either
POST https://192.168.178.30:8443/notes net::ERR_CERT_AUTHORITY_INVALID
or
POST https://192.168.178.30:8443/notes net::ERR_CERT_COMMON_NAME_INVALID
I have installed the cert as a trusted root certificate as outlined here.
I set the common name on the cert as the IP address (192.168.178.30) but chrome still won't accept it, and I don't have a domain name (it's running locally).
So my question is: how do I either make a trustworthy OpenSLL certificate, or force chrome to ignore such errors. I have a day to get this working along with other aspects of the application so I ned a quick fix. This is for the purpose of a demonstration, it is not going live to the internet.
Related
I've seen this question around here on the forums only what I wish to know slightly differs from the ones I already read I suppose.
I will give you an example of the problem I am facing:
Let's say a hacker has managed to infiltrate the system and is able to spoof a DNS. Now if this hacker would clone a website, let's say this website is facebook, what I have read so far he would be making a HTTP website, because HTTPS would show up as faulty.
Now what I'm wondering is that with modern SSL it would seem like everyone is able to get his own certificate for his website. So if someone would connect to that website it would say the connection is trusted because it's SSL with a legit connection.
So what if this hacker would add a certificate to his cloned/spoofed phishing website? Wouldn't this mean that me as a user would go to his facebook page, and in the search bar it would say the connection is legitimate ( Because he added a certificate ) ? Because if that would be the point it would be necessary to check the certificate of every website I open at all times to see if it's actually the certificate that belongs to facebook (For example.)
Please let me know if anyone has any knowledge about this I am very curious to see how this works!
Provided that
Let's say a hacker has managed to infiltrate the system and is able to
spoof a DNS.
means that the attacker has control over the records for the name facebook.com (in orther words, he can point www.facebook.com to an IP of his choice) then yes, your scenario is correct.
He would
redirect www.facebook.com to site of his
buy a certificate for www.facebook.com
Someone going to that site would then see (www.facebook.com would be the domain)
This means that the traffic to access to this site is correctly secured between the browser and that site, and nothing else. Specifically, this does not tell if the site actually belongs to Facebook.
There are some sites which go one step further, with Extended Validation Certificates, where the issuer does some checks to "ensure" that the certificate is delivered to the actual owner of the service. You the see something like
As you can see, the owner of the site is visible right on the toolbar. Other browsers usually use a bright green toolbar to signal such sites.
Not sure if that is what you're asking, but you have trusted CAs imported to your browser (by default).
The attacker would need to have a key signed by trusted authority for this particular domain. I do not expect that to happen.
Another option would be breaking the key - very unlikely with current technology/regular updates made by major browser providers.
Major browsers providers are deprecating vunerable alghorighms to make sure you're OK.
For instance - Recently for that reason SHA1 got depreceated.
See here for more details on SHA1:
https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#pjXdGbOji3itBI7v.97
https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html
https://www.google.com.au/search?q=firefox+sha1+deprecation&rlz=1C5CHFA_enAU714AU715&oq=firefox+sha1&aqs=chrome.1.69i57j0l5.2293j0j4&sourceid=chrome&ie=UTF-8
)
To summarize - your browser will let you know that there is 'something wrong' with the site (warning instead of green box).
Simply check the green box (and domain). Keep your browser updated.
Also for more information about SSL handshake see here: https://www.ssl.com/article/ssl-tls-handshake-overview/
I've got a requirement to detect if a webpage is being served on the internet or intranet, i.e. assuming a url of https://accessibleanyway.com, is the phone connected to the work wifi or to something else like their home wifi or the phone network?
What different ways are there to do this?
(1) Use WebRTC to get the local ip address. Not widely supported
(2) Try to access a local web page using jsonp/cors/iframe
The problem with 2 is that the webpage is https and the local resource is likely to be http which you can't do in IE afaik. If I make the local resource https then it's via a self cert which means installing CAs on the phones (can you buy certificates for the intranet anymore?)
Any suggestions?
The problem with (2) was that the same page was trying to use http and https, and even with an iframe you get issues.
What you could do instead is start on a http loading page, use an iframe to access a local resource which you can only access if you are on the intranet, jsonp will work fine for this. Once that's worked or failed, redirect to your start page with some token in the querystring to indicate that you are on the intranet or not
NB jumping from http to https would probably have some security issues if you are on the same website (authentication cookies being initially visible), but I would have thought it would be fine if you are going to a different one
Obviously there'll be some security needed around the token as otherwise the user could just generate their own but that's a different matter which depends on individual setups. It would obviously have to be generated by a server call, otherwise someone could just read the client code.
NB I think the IP address approach is never going to work as you have no way of knowing what a companies intranet setup looks like until you go there, so it's not a generic answer
One of customers have reported that they can see the password being transferred as clear text, they probably tried tool like a fiddler to capture the HTTP request/response. So my question is is it possible using fiddler or any other tool is it possible for someone to monitor the http traffic on that local computer at the moment the user entered the password and clicked to login ?
If the user is accessing the website without using SSL (i.e. by going to "http://" instead of "https://"), then it is possible to see all of the traffic between the website and the browser, and not only on the local computer but also on the network that the computer is connected to.
If the user is accessing the website via HTTPS, Fiddler is able to act as a proxy and decrypt the traffic between the browser and the server by using a special SSL certificate (thanks to #user18044 for clarification in the comments below).
In your case Fiddler is NOT accessing browser memory directly to get to the password in clear text.
I have a site which is completely on https: and works well, but, some of the images served are from other sources e.g. ebay, or Amazon.
This causes the browser to prompt a message: "this website does not supply identity information"
How can I avoid this? The images must be served from elsewhere sometimes.
"This website does not supply identity information." is not only about the encryption of the link to the website itself but also the identification of the operators/owners of the website - just like it actually says. For that warning (it's not really an error) to stop, I believe you have to apply for the Extended Validation Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificate. EVC rigorously validates the entity behind the website not just the website itself.
Firefox shows the message
"This website does not supply identity information."
while hovering or clicking the favicon (Site Identity Button) when
you requested a page over HTTP
you requested a page over HTTPS, but the page contains mixed passive content
HTTP
HTTP connections generally don't supply any reliable identity information to the browser. That's normal. HTTP was designed to simply transmit data, not to secure the data it transmits.
On server side you could only avoid that message, if the server would start using a SSL certificate and the code of the page would be changed to exclusively use HTTPS requests.
To avoid the message on client side you could enter about:config in the address bar, confirm you'll be careful and set browser.chrome.toolbar_tips = false.
HTTPS, mixed passive content
When you request a page over HTTPS from a site which is using a SSL certificate, the site does supply identity information to the browser and normally the message wouldn't appear.
But if the requested page embeds at least one <img>, <video>, <audio> or <object> element which includes content over HTTP (which won't supply identity information), than you'll get a so-called mixed passive content * situation.
Firefox won't block mixed passive content by default, but only show said message to warn the user.
To avoid this on server side, you'd first need to identify which requests are producing mixed content.
With Firefox on Windows you can use Ctrl+Shift+K (Control-Option-K on Mac) to open the web console, deactivate the css, js and security filters, and press F5 to reload the page, to show all the requests of the page.
Then fix your code for each line which is showing "mixed content", i.e. change the appropriate parts of your code to use https:// or, depending on your case, protocol-relative URLs.
If the external site an element is requested from doesn't use a SSL certificate, the only chance to avoid the message would be to copy the external content over to your site so your code can refer to it locally via HTTPS.
* Firefox also knows mixed active content, which is blocked by default, but that's another story.
Jürgen Thelen's answer is absolutely correct. If the images (quite often the case) displayed on the page are served over "http" the result will be exactly as described no matter what kind of cert you have, EV or not. This is very common on e-commerce sites due to the way they're constructed. I've encountered this before on my own site AND CORRECTED IT by simply making sure that no images have an "http" address - and this was on a site that did not have an EV cert. Use the ctrl +shift +K process that Jürgen describes and it will point you to the offending objects. If the path to an object is hard coded and the image resides on your server (not called from somewhere else) simply remove the "http://servername.com" and change it to a relative path instead. Correct that and the problem will go away. Note that the problem may be in one of the configuration files as well, such as one of the config.php files.
The real issue is that Firefox's error message is misleading and has nothing to do with whether the SSL is an EV cert or not. It really means there is mixed content on the page but doesn't say that. A couple of weeks ago I had a site with the same problem and Firefox displayed the no-identity message. Chrome, however, (which I normally don't use) displayed an exclamation mark instead of a lock. I clicked on it and it said the cert was valid (with a green dot), it was a secure connection (another green dot), AND had "Mixed Content. The site includes HTTP resources" which was entirely accurate and the source of the problem (with a red dot). Once the offending paths were changed to relative paths, the error messages in both Firefox and Chrome disappeared.
For me, it was a problem of mixed content. I forced everything to make HTTPS requests on the page and it fixed the problem.
For people who come here from Google search, you can use Cloudflare's (free) page rules to accomplish this without touching your source code. Use the "Always use HTTPS" setting for your domain.
You can also transfrom http links to https links using url shortener www.tr.im. That is the only URL-shortener I found that provides shorter links through https.
You just have to change it manually from http://tr.im/xxxxxx to https://tr.im/xxxxxx.
I was using google SSL search (https:www.google.com) with the expectation that my search would be private. However, my search for 'toasters' produced this query:
https://encrypted.google.com/search?hl=en&source=hp&q=toasters&aq=f
As you can see, my employer can still log this and see what the search was. How can I make sure that when someone searches on my site using SSL (using custom google search) their search terms isn't made visible.
The URL is sent over SSL. Of course a user can see the URL in their own browser, but it isn't visible as it transits the network. Your employer can't log it unless they are the other end of the SSL connection. If your employer creates a CA certificate and installs it in your browser, they could use a proxy to spoof Google host names, but otherwise, the traffic is secure.
HTTPS protects the entire HTTP exchange, including the URL, so the only thing someone intercepting network traffic will be able to determine is that there was communication between the browser and your site (or Google in this case). Even without the innards, that information can be useful.
Unless you have full administrative control over the systems making the queries, you should assume that anything transpiring on them can be intercepted or logged. Browsers typically store history and cache pages in files on the local disk which can be read by administrators. You also can't verify that the browser itself hasn't been recompiled with code to log sites that were visited, even in "private" mode.
Presumably your employer provides you with a PC, the software on it, the LAN connection to its own corporate network, the internet proxy and corporate firewall, maybe DNS servers, etc etc.
So you are exposed to traffic sniffing and tracing at many different levels. Even if you browse to a url over SSL TLS, you have to assume that the contents of your http session can be recorded. Do you always check that the cert in your browser is from google and not your employer's proxy? Do you know what software sits between your browser and your network card, etc.
However, if you had complete control over the client, then you could be sure that no-one external to your https conversation with google would be able to see the url you are requesting.
Google still knows what you're up to, but that's a private matter between your search engine and your conscience ;)
to add to what #erickson said, read this. SSL will protect the data between the connected parties. If you need to hide that link from the boss then disable the browser caching of the sites visited, i.e. disable or delete the history data.