Currently Azure Websites don't allow custom SSL certificates, but they have wildcard SSL enabled for the *.azurewebsites.net domain. I need a secure login form for my web app, but with no custom SSL, it appears that I'm SOL.
Is there any kind of workaround for this? Would it be possible somehow to have a login form at https://mydomain.azurewebsites.net that creates a forms authentication ticket that will then work at http://mydomain.com?
Couple of months ago I had exactly the same problem i.e. application was built on Azure Websites, had to run on custom domain other than *.azurewebsites.net and had to allow secure login process.
Workaround for that we used was to embed an iframe (using secure protocol and .azurewebsites.net domain name e.g. https://oursite.azurewebsites.net/login) into non-secure page on custom domain (e.g. http://mysite.com/login). And entire login process was performed in the iframe.
There is one thing which you should be aware of, namely, lots of customers checks whether the page where they provide their credentials was using secure connection or not. In our case, secure iframe in non-secure page was causing lots of customer complains. Workaround for that problem was to put a message confirming that the login process uses secure connection. The message made some improvements, however, still certain number of customers complains remained.
I hope that will help.
This isn't really an answer to your question, but Microsoft are very aware that custom mapped SSL to websites is one of the most requested features for Azure websites and they have said they are working on it.
Scott Hanselman himself confirms it here
In the meantime, Tom's answer is a perfectly valid workaround.
One thing I would be very wary of though is with something Tom brings up: the security warning that the browser will present. You'd be amazed how many people freak out when they see that message and don't go any further! We have a fairly active ecommerce site and there have been occasions where we have accidentally used a none secure image path on an SSL page and we have always received emails from customers asking if our site has been hacked or similar!
The disclaimer that Tom mentions is a good idea, but I think it will still put some people off.
I am working directly with the WAWS team right now to produce some public guidance for this. A GitHub repository with the requirements is currently being evaluated by the team (I sent it over to them literally 1 hour ago). Hopefully, the solution will be approved and made public within a few weeks.
I can say this - the workaround won't be fully supported or much custom guidance given on its usage aside from the repository and accompanying documentation. SSL is, literally, the #1 priority for the product, and hundreds of people are working insane hours to make it happen for everyone. This workaround should also be considered temporary, as you'll no longer need it once the full SSL functionality is launched.
Related
What is the best way to password-protect a folder on IIS with a single set of credentials to be shared by a group of users?
Our hosting service offers Plesk, which in turn offers a "password-protected directory" function, but some of our clients have HTTP authorization disabled, so they get an automatic 401.4 error with no prompt for credentials.
I've looked into Forms authentication but this seems cumbersome to set up for the numerous separate domains at issue.
The protected content is not super sensitive, we just don't want it easily accessible to the public. Many of our users do not use the site frequently and we don't want to implement individual credentialing for everyone (we do have that in place for more sensitive sections) just so they can view current project reports or meeting minutes.
On sites I don't control, but am just a user, that do the same things as mine, it is a big pain to have to look up a username and password twice per year just to view a meeting agenda (yes, browser could remember but they also have a 4-month expiration and lots of us are on different devices all the time).
Is Forms authentication the way to go? Took a several hours for me to get it set up and working, with all sorts of settings not well documented in a single place.
(I had previously asked about how to disable Basic Auth on the client side, was told more than once it's not possible - but it is, via client/browser registry keys)
Thanks.
It's perfectly fine to use forms authentication. All you need to do is navigate to the folder or file you want to protect, then go to Authorization Rules. Add a deny rule for anonymous users, when users who are not logged in try to click on any file in that folder, they will be redirected to your login page. You can find a lot of guides on forms authentication in Google, you can refer to the following:
https://learn.microsoft.com/zh-CN/troubleshoot/developer/webapps/aspnet/development/forms-based-authentication
https://learn.microsoft.com/en-us/iis/application-frameworks/building-and-running-aspnet-applications/how-to-take-advantage-of-the-iis-integrated-pipeline
Information you get from the internet is increasingly tailored specifically for "you".
Google search results or youtube comments ranking algorithms have way to much power not to be fully disclosed.
You can make a snapshot of a web site using a web archiving service and that service could testify its authenticity.
How could one have a similar "provable" snapshot for you specific user session?
Of course, if you give your access tokens to the archiving service they could testify it but how could that be done in a trustless way?
I thought about using a browser extension but nothing prevents someone from using a tempered browser build?
Could a proxy record of the encrypted communications be used somehow?
Would a provable link between it and the decrypted version of the interaction be possible without exposing the user private key?
Are there any methods already available?
If not...any ideas?
Thanks
edit:
TC "kind of" solves the "secured against its owner" that I'm assuming browser extension also solve but I don't think TC would help since you can just build your own version of the browser.
If that would be possible and a "man-in-the-middle attack" could be prevented then a simple "webRTC tab sharing" record would do it (or some other king of record and replay method)
I was thinking in more in some kind of method where you would log into the site and "only" after that all communications would go through a proxy.
You would record you interaction with the site and close the connection.
Then you would give the TLS key and all the saved interaction to the proxy and it would be able to replay that interaction with the cached network traffic.
Is something like that possible?
I'm trying to set a web service that needs the user's Google Latitude info, so I'm using Google OAuth to get the user authorization stuff.
However, when trying to set the redirection URI in the Google APIs Console for a web application client ID I get a message error if I try to set it to 'http://PUBLIC_IP/'.
I need to test it with non local users (thus localhost can't be used), so I would like to know if having a web domain is mandatory in order to use Google's OAuth. If not, how can I solve this issue?
This is not currently supported. I filed a feature request and will update on progress.
Update: Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can use xip.io to work around it.
For example: '192.168.0.50.xip.io:3000' will resolve to '192.168.0.50:3000'
I ran into this issue too and so I entered a URL with a .com extension and also entered it into my /etc/hosts file. Works like a charm.
It totally sucks that my entire app now has to be developed on an apparently 'live' domain though.
I used my public hostname. It helps if you have a static IP address. I used http://www.displaymyhostname.com/ to get my hostname. I plugged it straight into the Authorized JavaScript origins field when I created a new Web Application Client ID.
P.S. My hostname looked something like this: 111.111.111.111.static.exetel.com.au
You can use a dynamic DNS. I used ddns.net which offers a free solution. Basically, you enter your FQDN as this: yourcompany.ddns.net as your domain. When looked up for an IP address, the .net domain points to ddns; when ddns.net is looked up, it looks up in its database for your company, returns the IP. So mine looks like this: https://wigwam.ddns.net and everything works fine. You don't need to buy a domain, you can substitute your known IP, and Google is happy with that.
Your IP must be static, of course.
Yes, as of now you still need to have a domain name to use Google OAuth in your application. If you have a static public IP and don't want to buy a domain name, you could use a free subdomain from FreeDNS to link to your public IP. Seemed to work well enough for me with a Django app.
Echoing what Breno said in response to his earlier comment:
Apologies for the lack of updates here. Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can read more about Google's app verification requirements [1] and Google's policies requiring secure handling of data [2].
[1] https://support.google.com/cloud/answer/9110914?hl=en
[2] https://developers.google.com/identity/protocols/oauth2/policies#secure-response-handling.
xip.io is not working anymore as an alternative you can use nip.io the same way for example:
10.0.0.1.nip.io:8000 will resolve to 10.0.0.1:8000
It seems like xip.io is down, but there are alternatives such as sslip.io and nip.io. However, I couldn't get either of these to work.
I ended up hosting the main file server on the main machine, and ran said server on a 192.168.1.xx IP address. I then ran servers on each of the test machines (including a second server on the main machine), all of which were on the localhost address. Any requests that the localhost servers received were then passed off to the 192.168.1.xx server, which allowed testing on all of the devices.
This should also work with public facing IP addresses.
Currently, I have decided to use Drupal as the primary login area where users can do stuff. Problem is, I want to automatically allow for the logging in of users using their cpanel, whm or whmcs login details. Anyone?
I really don't suggest you to do this.
You will only introduce more risks to all your systems, even if Drupal is a very secure system.
There are sometimes authentication security issues, with cPanel drupal and whmcs. Now, imagine those security issues + the ones of drupal, + the ones on whmcs...
...with all these insecurity layers combined, it's a real security bomb, and not something that will help your customers that much you are going to create. ...plus your modules for this will probably experience someday security issues also.
I suggest to take a look at other web hosts : if they don't do this, and if even whmcs do not bridge with vbulletin on their own website, there is a reason for this! ;-)
There seems to be no module for this.
Also Drupal seems not to provide a direct way to connect 3rd party login systems.
Having a look at the LDAP integration (file ldapauth.module) in the package, you can use the hook hook_form_alter. The check whether the form is using user_login_authenticate_validate in the validate entry and replace it with their own authentication function.
Basically you can use the ldapauth.module file as a basis and start with the ldapauth_login_authenticate_validate function.
In this function you have to add code that uses $form_values['name']; and $form_values['pass'] and verify them against your cPanel database.
A completly different approach would be to write a cPanel module to create Drupal users and update the accounts. To get started you can have a look at writing cPanel modules.
I have a login screen which I'm serving over SSL. The user fills in their login/password, this gets POSTed to the server. At this point I want to jump out of SSL, so I redirect them back to the same page with no SSL.
This causes the browser to show a warning dialog "You are about to be redirected to a connection that is not secure". How can I avoid this? I've been plenty of sites like yahoo mail, and gmail that give you an SSL page for login, then send you to a non-SSL page after this.
Secondary question: what's the purpose of this dialog? It's trying to warn me about some nefarous purpose - but what's so bad about redirecting someone to a non-SSL page? I don't get a warning when I'm on an SSL page and click a non-SSL link. What's different about redirecting someone?
I'm doing this in ASP.NET 2.0 - but I figure this is a generic web-dev question.
UPDATE SUMMARY: It seems the popular answer is "DON'T AVOID IT". I can understand that a user should get a message when security it being removed. But I don't get a dialog when I follow a link and security is removed, so at the very least I'd say this is inconsistent.
The dialog / browser versions. I actually don't see the dialog in IE7/FF3 (maybe I've clicked a checkbox preventing it). More importantly the client DOES see it in IE6 - with no checkbox to remove it (yes, I know IE6 is old and crap).
Firefox2: FF2 http://img521.imageshack.us/img521/8455/sslwarning.jpg
IE6:
The alternative: make the entire site SSL, never redirect the user out of SSL. I could handle that. But I've got a semi-technical client who has some fairly good points:
"SSL is going to cause an increase in traffic / processing power". I don't really buy this, and I don't think his site is every going to require more than one box to serve it.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
I'm going to try sway the client over to an entirely SSL site. I'll argue Yahoo's approach made sense in 1996, or for a site that is MUCH more popular. Some official links explaining why this dialog happens would help (i.e Jakob Nielsen level of authenticity).
I've hit this same problem a while back. So I had a look inside fiddler to see how yahoo mail does it. Here's the step I saw (and used on my site):
User fills in SSL encrypted form, and POSTs to the server. Server authenticates, and spits out some script to redirect the client
<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>
I figure the client side code is there to avoid this dialog.
"How can I avoid this?"
You shouldn't!
Although you could try that with JavaScript. This might work on some browsers and fail on others.
"What's the purpose of this dialog?"
It warns because switching between SSL and non-SSL on websites is usually unexpected by the user. A warning about the "non-SSL to SSL" is not emitted since it increases security and privacy. However, when security is suddenly decreased, the user should notice that quickly, in order to avoid a false feeling of security. In fact, redirecting to a non-SSL site is sometimes used in XSS/MITM attacks.
"SSL is going to cause an increase in traffic / processing power"
This is nonsense. It might be true for sites full of big, static content. However, for normal dynamic web applications, encryption is very cheap compared to business logic, database access, etc.
There is an urban legend saying that SSL-content is not chached by browsers. See "Will web browsers cache content over https" for more information.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
Some rhetoric counter-questions:
Are you a big technical company like Yahoo?
Did being a big technical company prevent Microsoft from producing crappy software?
Do you have to support crappy old (SSL-broken) browsers, as Yahoo has to?
The attack this is preventing against is a man-in-the-middle SSL session strip. The message is there with good cause.
As for the purpose: It's to make you aware that your connection won't be SSL encrypted anymore. You may have seen before that the connection is encrypted and may think that it still is, so this warning says "Just to be clear, whatever data you send from here on will be plaintext".
As for how to suppress it: AFAIK you can't, it's a browser thing, what would be the point of the message otherwise? Even though there are workarounds like client-side redirects, I don't think you should try to work around client "problems" like this. If the browser chooses to be verbose, let it. There's a "Don't show this again" checkbox on the dialog after all If the user wishes to suppress this message he can easily do so, and maybe he actually likes to see it.
Also, IMHO, if the browser was worth its salt it would still pop up this warning, even if you employed client-side redirect tricks.
Use SSL for the whole page in the first place!
There's nothing wrong with SSL. You should provide user privacy everywhere, not only on login. It makes sense an the whole site. So simply redirect all non-SSL pages to SSL pages and keep everything SSL.
Just point your client to the latest attacks against mixed mode content (lookup CookieMonster on fscked.org) and proxy attacks (against sites available both in http and https, lookup Pretty-Bad-Proxy). He might reconsider.
It is much easier to get security right if you only deal with one protocol without mixing the two. SSL adds a bit of overhead, but it is nothing compared to the cost of a breach.
Gmail, yahoo, etc. use SSL for an encrypted iframe, which authenticates, but there's none of the in-page redirection you're talking about. The whole page isn't encrypted for these login systems.
read:
http://support.microsoft.com/kb/883740
which says that this is fixed in a hotfix or with a changed registry setting. However, not all the IE6 cpu's we use have this problem, nor do their registry settings correspond to what this article says they should. Also some that give the msg are XPsp3 and IE6 sp3.
We have an https log in screen that uses code to log into 15 other (http) domains and some of our IE6 users have to click 'Yes' 15 times. This is inacceptable to them.
No, we cannot control what browser all our users use. Some are not compatible with upgrade to IE7.
We are looking for some config attribute for each user to adjust that will suppress this msg. We've identically configed a 'bad' browser with settings that match one that does not give the msg. Internet and Intranet Security and Advanced settings and Proxies (none).Also Network connections. No joy so far.
Any ideas?