So I made a contact form in Laravel 5, that's completely working. It basically posts the email, name and message to a variable and sends me an email with them. Is this secure enough for real life use without an SSL cert?
My project files are outside of the public_html folder if that makes a difference. I want to have this usable (security-wise), but don't want to pay a ton of money for an SSL cert on a site hardly anyone will go on.
Any answers appreciated
SSL is always recommended, but if the contact form shouldn't get any sensitive data, then you can live without it.
Though now you can get SSL certs for free from LetsEncrypt.
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/
That one is a tricky question.
The setup is the following :
A dashboard on my Apache server on a subdomain of a client's company website.
http: //sub.domain.com
The dashboard gets realtime info from a Socket.IO server on port 5000 of the same subdomain (same machine).
http: //sub.domain.com:5000
Everything is alive and well... but it is not quite :)
Original problem (kinda solved but needed for understanding):
Some antiviruses block unsecure Websockets (ws://), which is probably a good thing. Given that I can't ask my users to disable their AV, I generated a self-signed certificate, made modifications to my Node server, and all good, traffic goes through.
New Problem :
Self signed certs are invalid, the kind that require you to click 'Proceed' to go through. As I serve only socket messages, I don't have this opportunity to click a button, and therefore get a 501::INSECURE RESPONSE. once again, normal, but very annoying in this case. I have to serve a blank html page, just to be able to click this button, not something I can justify to my users either...
I couldn't find a way to get (free or cheap preferred) a valid SSL certificate for a subdomain (sub.domain.com). And I don't want to spend money if I'm not sure it'll work. Any ideas?
Edit :
The easiest way I found, although temporary I hope is a double redirection, user gets to the main login page, gets reddirected to the https node server, adds exception, and is redirected back. Ugly but...
I am new to development and at my new job we have this issue where on a sub-domain users are getting the error you see below but when they go to the base domain (e.g: domain.com) they don't see that.
I am supposed to solve this but not sure what might be causing it. I am not looking for somebody to solve this for me but if you can outline possible reasons why, i would be very thankful.
First thing: open up the "Technical details". They will give you more information, information you might or might not yet fully understand, but it still have the necessary info.
Basically, SSL (https) certificates are created for a specific domain. If the domain name changes (from e.g. example.com to foo.example.com), the certificate can not be used without a security warning popping out.
You need to create (either by self-signing or purchasing) separate SSL certificates for all the host names/domains under which the site will be accepted, to avoid the security warning. An alternate option is to purchase a wildcard certificate for the entire domain and sub tree (ie: *.example.com).
There are, to the best of my knowledge, no other ways around this; it's one part of how the HTTPS security is established.
When you're running HTTPS, you should have a different certificate for each server (subdomain) not each domain and the client should trust it if you don't want them to see this error.
You can use a wildcard certificate also. It would inherit through all subdomains.
First, let me admit that what I know about HTTPS is pretty rudimentary. I don't know much about session security, encryption, or how either of those things is supposed to be done.
What I do know is that web security is important; that horror stories of XSS, CSRF, and database injections pop up over and over again. I know that a preventative stance against such exploits is better than a reactive one.
But the motivation for this question comes from a different point of view. I work at a site that regularly accepts payment from users. Obviously, the payments are sent over a secure channel (HTTPS). I mainly work on the CSS, HTML, and JavaScript of the site. What I've been told is that it is necessary to duplicate CSS, JavaScript, and image files before they can be called over HTTPS. So assume I have the following files:
css/global.css
js/global.js
images/
logo.png
bg.png
The way I understand it, these files need to be duplicated before they can be "added" to the HTTPS. So a file can either be under security (HTTPS) or not.
If this is true, then this is a major hindrance. In even the smallest site, it would be a major pain to duplicate files and then have to maintain them every time you make a CSS or JS change. Obviously this could be alleviated by moving everything into the HTTPS.
So what I want to know is, what are the pros and cons of a site that is completely behind HTTPS? Does it cause noticeable overhead? Is it just foolish to place the entire site under encryption? Would users feel safer seeing the "secure" notifications in their browser during their entire visit? And last but not least, does it truly make for a more secure site? What can HTTPS not protect against?
You can serve the same content via HTTPS as you do via HTTP (just point it to the same document root).
Cons that may be major or minor, depending:
serving content over HTTPS is slower than serving it via HTTP.
certificates signed by well-known authorities can be expensive
if you don't have a certificate signed by a trusted authority (eg, you sign it yourself), visitors will get a warning
Those are pretty basic, but just a few things to note. Also, personally, I feel much better seeing that the entire site is HTTPS if it's anything related to financial stuff, obviously, but as far as general browsing, no, I don't care.
Noticeable overhead? Yes, but that matters less and less these days as clients and servers are much faster.
You don't need to make a copy of everything, but you do need to make those files accessible via HTTPS. Your HTTPS and HTTP services can use the same doc root.
Is it foolish to put the whole site under encryption? Typically no.
Would users feel safer? Probably.
Does it truly make for a more secure site? Only when dealing with the communication channel between the client and the server. Everything else is still up for grabs.
You've been misinformed. The css, js, and image files need not be duplicated assuming you've set up the http and https mapping to point to the same physical website on the server. The only important thing is that these files are referenced with https when the page you're looking at is also under https. This will prevent the dreaded security message that says that some objects on the page are not secured.
For every other page where you're running the site under http (unsecured) you can reference those same files in the same locations, but with an http address.
To answer your other question, there would indeed be a performance penalty to put the entire site under https. The server has to work hard to encrypt everything it sends over the wire. And then some not-so-old browsers won't cache https content to disk by default, which of course will result in an even heavier load on the server.
Because I like my sites to be as responsive as possible, I'm always selective about which sections of a site I choose to be SSL-encrypted. In most typical e-commerce sites, the only pages that need SSL encryption are the login, registration, and checkout pages.
The traditional reason for not having the entire site behind SSL is processing time. It does take more work for both the client and the server to use SSL. However, this overhead is fairly small compared to modern processors.
If you are running a very large site, you may need to scale slightly faster if you are encrypting everything.
You also need to buy a certificate, or use a self signed one which may not be trusted by your users.
You also need a dedicated IP address. If you are on a shared hosting system, you need to have an IP that you can dedicate to only having SSL on your site.
But if you can afford a certificate and private ip and don't mind needed a slightly faster server, using SSL on your entire site is a great idea.
With the number of attacks that SSL mitigates, I would say do it.
You do not need multiple copies of these files for them to work with HTTPs. You may need to have 2 copies of these files if the hosting setup has been configured in such that you have a separate https directory. So to answer your question - no duplicate files are not required for HTTPs but depending on the web hosting configuration - they may be.
In regards to the pros and cons of https vs http there are already a few posts addressing that.
HTTP vs HTTPS performance
HTTPS vs HTTP speed comparison
HTTPs only encrypts the data between the client computer and the server. It does not software holes or issues such as remote javascript includes. HTTPs doesn't make your application better - it only helps secure the data between the user and your app. You need to make sure your app has no security holes, practice filtering all data, SQL, and review security logs frequently.
However if you're only responsible for the frontend part of the site I wouldn't worry about it but would bring up concerns of security with the main developer for the backend.
One of the concerns is that https traffic could be blocked, for example on Apple computers if you set parental control on it blocks https traffic because it can't read the encrypted content, you can read here:
http://support.apple.com/kb/ht2900
https note: For websites that use SSL
encryption (the URL will usually begin
with https), the Internet content
filter is unable to examine the
encrypted content of the page. For
this reason, encrypted websites must
be explicitly allowed using the Always
Allow list. Encrypted websites that
are not on the Always Allow list will
be blocked by the automatic Internet
content filter.
An important "pro" for more https at your site is the following:
a user connecting thru an unencrypted WiFi, like at an airport, can give their password in https, but if the site then switches back to http after the password page, the session cookie becomes exposed and can be immediately used by an eavesdropper.
See this article http://steve.grc.com/2010/10/28/why-firesheeps-time-has-come/#comment-2666
We extensively use a third party app that we'll call thirdparty.com. thirdparty.com and mysite.com have a common navigation and look and feel, so to the users, they think they are always on mysite.com.
What we're going to do is start url rewriting 3rd.mysite.com to display thirdparty.com, to make it look even more like a seamless experience. This also gives us access to thirdparty.com's cookie, because it will be written as mysite.com.
thirdparty.com has an SSL cert that they use for a few select transactions (basically just login). When you call https://3rd.mysite.com/login, you get a 404 as mysite.com does not have SSL. So we're going to install an SSL cert to the 3rd.mysite.com subdomain to alleviate this problem.
The question is, if we install a EV SSL certificate, will the user see that, or will it relegate to the cert from thirdparty.com? I can think of reasons for this to work both ways, but am looking for a definitive answer. If they see the SSL cert, then there's no sense wasting money on the EVSSL. If they see the EVSSL, I'd think that would be a big opening for phishing if someone was doing this illegitimately.
Cheers
If user agents see the site as thirdparty.com they are going to require an https certificate for thirdparty.com. So if that's an EV cert, then they are indeed going to see the green glow. Of course, you will want to make sure any communications between thirdparty.com and mysite.com should be appropriately secure.
(BTW: rfc2606 for example domain names.)
Disclaimer: I'm not really competent to answer this question, but this is stackoverflow.