I have an app that uses NSURLSession to run .php files on a web server. The directory on the web server is password protected and the didReceiveChallenge delegate is working perfectly, returning the user name and password. Up until now this has all been over HTTP as it has simply been a proof of concept, and is therefore open to man-in-the-middle threats.
As I near completion I am going to switch to HTTPS using a trusted cert and am wondering what additional steps I need to take (if any) with NSURLSession to communicate with a secure connection, or will it be as simple as switching the url in the session from HTTP to HTTPS once the server is setup. This will NOT be a self signed cert.
I have found similar questions on here, but none that have an answer.
Thanks!
So I went ahead and installed a self signed certificate on my web server, and then simply changed the HTTP to HTTPS in NSURLRequest and all seems to be working just fine!
Related
I've read a lot of questions and answers about this topic, but nothing I've seen has helped. I have web app with a node/express backend and an aurelia client. It's one of three I have running in the same subdomain. One of the others has a certificate and the other doesn't. Both of them work perfectly. The new app doesn't have a certificate, but it insists on redirecting all requests to https.
In chrome I've deleted the domain security policy and cleared my cache and I get the same result. It doesn't matter which browser I use. I've even tried a browser I've never used to access the app with a certificate and I get the same result.
The server code is essentially the same as for the app which doesn't use a certificate.
I'd appreciate any suggestions.
Ross
I have ws working for sending user login details through a websocket. However I know that someone sniffing packets could capture the password, so I wanted to use wss instead. However I now understand, through playing around with my back end, that firstly a certificate is required for it to connect properly, and secondly, if i cause the self signed certificate warning to sho0w, afterwards the websockets will work with wss, but that is not good enoyugh for clients. From googling this issue, I have found that A self signed certificate will probalby not be good enough.
And all I want is to provide a user with a safe way to login.....
So anyway I am now thinking it would be better to avoid having to use wss all together. I could use a conventional servlet for login but that will probably require a certificate too for https and I don't want to have to start paying people loads of money for certificates when my business might not even be that successful.
I have been thinking about other ways I could send the users password securely. One way might be to generate a hash in the browser. I know I could use some king of challenge along with a salt sent to the browser but I am not exactly sure how to do this and how safe this would be. I have the conventional login working with a salt, generating a hash with AES. Any suggestions?
I just want the users login details to be safe and I don't want to go down the route of certificates, it's annoying and unreliable.
Login should always happen through HTTPS. Not only the POST sending the user and password, but also the GET getting the login form, so the client can be sure is getting the right form and that his information will be posted to the right place.
You can send login details either by HTTPS or WSS if you want security. If you use a self-signed certificate you will provide transport security, but as the certificate is not signed by a CA, the client cannot be sure that the server with which is interacting is the right one, and that is why the browser shows a warning.
So, if you want security for your clients, you should get a signed certificate and use it for HTTPS and WSS (you can get them from 10 bucks per year in some places). Anything that you do in the browser is insecure by default, starting by the user not having certainty of being interacting with the right server and not a spoofed one.
Found this blog helpful even though it's directed to the raspberry pi and python/nodejs. http://simplyautomationized.blogspot.com/2015/09/5-ways-to-secure-websocket-rpi.html
Good concepts on security and authentication. I would recommend ALWAYS using ssl and not rolling your own crypto.
Is it good enough a protection if my site is serving on https with secure session cookie and redirects any attempts for http urls to https?
What kind of security holes can i be exposed in this setup to for which i cannot live without setting the HSTS header?
This strategy protects against passive eavesdropping by making it hard for an attacker to trick your user into using something other than SSL to access your site. It also probably ensures that any bookmarks users store will point to the https URLs, which is good. However, HSTS still offers advantages in the event of a man-in-the-middle attack.
The core of the problem that HSTS tries to solve is that the browser doesn't know whether a given site should be using SSL or not. And most users don't explicitly try SSL first; if they type in a URL, they generally go to the non-SSL http site first, and usually they're just following links. If an attacker can trick your user into going to your site via an http URL and can sit in the middle of the user's traffic (by being their wireless AP, for example), that attacker can launch a man-in-the-middle attack against your site by proxying the user's traffic to your site and presenting the site to the user without SSL (this is a type of downgrade attack). Since the user won't see SSL, their browser won't recognize that the attacker doesn't have a valid certificate for your site and that they're not connecting to your site directly. (A more complicated approach would be to intercept the SSL traffic and present a self-signed or otherwise invalid certificate for your site, but this will normally result in browser warnings.)
In this scenario, redirecting non-SSL users to SSL or setting the secure flag on cookies doesn't actually help you very much. The man-in-the-middle attacker will be connecting to your SSL site (and proxying the user's actions to it), and will just remove the secure flag from your cookies when passing them along to the user.
The attacker can, of course, also remove the HSTS header. The point of the HSTS protocol, however, is that if the user had ever successfully gone directly to your site in the past, their browser will remember that your site sent HSTS. If they then later connect to your site and find that it's not using SSL or that the browser can't verify the certificate, the browser will throw an error and refuse to continue. This will prevent the attacker from downgrading your site to non-SSL if the browser supports HSTS and has your site recorded as requiring SSL.
Wikipedia has a fairly good discussion of this, which I think is somewhat clearer than the discussion in the RFC.
Our project(web application C# ASP.NET MVC3) is hosted on IIS 7.5 and we use certificate authentication. So we have SSL-require configured IIS.
Now we have a business task to allow some users to use our system. And there is no way to provide client certificates for them. In that case we need to use some additional authentication model (user-password or ntdomain based).
I don't know how to realize such model:
User gets on our project url;
If he has valid client certificate - we let him iteract with our application;
If he hasn't cert we show him a login form with "user-password";
If we use SSL-required configured IIS users would not be able to iteract with application without valid certificate at all right? And how to authenticate with certificate if IIS is configured with SSL-Accept?
Maybe you can configure two sites on your IIS? One with SSL and another without it? Your url will point to the SSL enabled site, and when a user without a valid certificate arrives you use some backup code to send him to the SSL free site?
Just guessing actually... I think this probably deserves a more meditated answer...
The problem was not so large as i thought before. IIS provides a check box to require certificate even if combobox(in SSL options of web application) is set to Accept instead of require. In that case IIS tries to get certificate at first. And if there is no cert it lets the user to iteract with application. And we can make custom authentication on that level.
With MVC (v.3+) there is nice way to use IAuthorizationFilter in that case
The Problem:
I am creating a vb6 application that will connect to a particular web service located on a a HTTPS site. The problem is, the HTTPS site I'm accessing requires all request to accept it's certificate policy. (as its a self-signed ssl certificate)
Basically I need the application to accept security certificate dialog boxes automatically. A sample security dialog is shown below:
Cheers in advance.
#EDIT:
I Cant' post an image yet as i am a new user... Please see the url below for a sample image:
http://oit.nd.edu/network/nomad/images/ie_certs.gif
Look for a property named Silent.
You will have to catch some other event, to reply to that dialog box. Although, I am not sure what is the behavior, if you set the Silent to true (i.e does it assume it to be Yes or otherwise?).
Most of HTTPS sites I know use self-signed certificates.
I don't know VB6 APIs for HTTPS, but for example in Java you should provide it a copy of the site certificate beforehand. That is:
export a copy of the certificate, for example from your browser certificate repository (in Firefox: Tools->Options->Advanced->Encryption->View Certificates etc.) - supposing you have have already visited the site with your browser;
detect which certificate repository your HTTPS API points to (there certainly is one)
import certificate into that repository
execute your program