We have a site at work that is used for the following:

  1. Our homepage, which is just some info and contact info.
  2. Job applications are also handled on our site.

There is no place where you can login though.

I told management, seeing that we are a company that does software engineering, it would make a better impression on potential clients if our site had an SSL certificate and if we enforced SSL automatically on anyone's browser that visits the site.

Also, even though we use Google’s business Gmail, we still use the same domain name for our website as we use for email. In other words, [email protected] and our site is company.com. In other words, potential clients would also get a bad impression if they realised we had no SSL certificate, as they would think that our email server is not sending over TLS.

Should we have an SSL certificate even though no "sensitive" or "important" data that needs to be encrypted will be sent or retrieved from our site?

  • 28
    Do your job application forms not require any personal information?
    – apsillers
    Commented Jul 12, 2013 at 13:34
  • 1
    I agree with apsillers. Information on a job application IS Sensitive and Important data and it DOES need to be encrypted. Commented Jul 12, 2013 at 14:14
  • 4
    Name and address alone are PII.
    – Polynomial
    Commented Jul 12, 2013 at 14:46
  • 1
    It's also easier in terms of policy and development to require SSL globally on the site in case you ever expand the capabilities.
    – CLo
    Commented Jul 12, 2013 at 16:18
  • 2
    Equally, using SSL prevents intermediate proxies/routers from appending scripts to the page, as is the case with the upside-down-ternet
    – jackweirdy
    Commented Jul 12, 2013 at 17:04

8 Answers 8


It's all about what you're trying to achieve and/or mitigate with the use of SSL. Random people on the Internet cannot assess your company's information. So you need to keep this in mind: it all depends on the risk, the probability of the risk, and how far you would go to mitigate that risk.

@apsillers brings a good point about your job application forms as potential candidates will be submitting personal information with the confidence that they will go to the intended receiver. I also agree with the point about the appearance of a secure website and a more professional attitude when flashing that padlock to a potential customer, especially if your IT company offers security consultation, then it might be a good idea to use HTTPS.

Personally, I always lean towards using HTTPS, even for a Hello Kitty website.

  • I agree. I would only not use SSL if the site is not taking ANY data at all. Commented Jul 12, 2013 at 14:12
  • 39
    My data on Hello Kitty is very serious.
    – Simon
    Commented Jul 12, 2013 at 14:50
  • Also if you enforce SSL then the site would be hard to spoof as you would need to perform an SSL MITM attack with something such as SSLStrip. But if the site is only on port 80, then arp spoofing would work. (Correct me if I'm wrong.) It could be a big threat for example if someone spoofed our site and told everyone that our company no longer exists.
    – MyMichelle
    Commented Jul 12, 2013 at 21:21
  • 1
    @PsudeoReality Agreed. I would place the bar at "if your website does not have any forms, with the exception of a search bar, it is probaby okay to not use SSL." Otherwise it should be in use.
    – Anorov
    Commented Jul 13, 2013 at 17:06
  • Currently https://hellokitty.com throws an SSL error because it uses a self-signed certificate which is also expired since 2011. The US company website uses state-of-the-art TLS 1.2 with ECDHE-RSA - as it should be. But the website of the Japanese main company is only partially encrypted: Many images are unnecessarily referenced by explicit http url's. Also, it uses the weaker RSA algorithm without forward secrecy.
    – Philipp
    Commented Oct 27, 2015 at 0:18

The fact that your website might have job application forms is a sufficient reason to have SSL. In particular, users expect to enter some personal information into your website, but they don't know precisely what information.

Letting an eavesdropper read the contents of a job application is bad, but it gets worse. Even if your application form doesn't have tremendously sensitive information (name, address, public resume info), an active attacker could rewrite your form to make it substantially more comprehensive. Maybe you don't ask for a social security number on your form, but your users don't know that. They might be perfectly happy filling out an attacker-modified form with slightly more intrusive data requests.

If you don't handle applications directly on your site, but only provide a contact number for your HR department, that's pretty bad too: an attacker could easily rewrite your contact information to his cell phone number and take the victim's personal information over the phone. (Of course, SSL stripping might make SSL less useful here. While a user might balk at sending personal information over an unsecured connection, even a reasonably contentious user might not think twice about accepting a phone number provided over an unsecured connection. You can mitigate SSL stripping by using HTTP Strict Transport Security, which tells the user's browser never to accept insecure connections from a particular source.)

In sum, sensitive information works both ways:

  • Any sensitive information users send to your site should be encrypted. "Sensitive information" might include log-in forms and session cookies, but it might also include personal information or even which pages they choose to request from your site. (For example, looking up tax-help resources from the IRS for particular sensitive topics might reveal information about recent large purchases, major life events, etc.)

  • Any information that your site sends to your users should be encrypted, if there could be significant harm from that information being altered. In particular, giving attackers the ability to rewrite contact numbers is a significant risk, as described above. Perhaps the only case where this requirement doesn't apply is if your website doesn't contain worthwhile information and the user is unlikely to be tricked into thinking that it should.

  • 2
    Also if an attacker just compromised a network and is trying to find out who is on the network sniffing the traffic and finds a job application go unencrypted over the wire he will be so happy. You may not get SSN but you probably get name, address and phone number at least. That would be enough for the attacker to call the victim as if the attacker worked for your company and ask the victim for his SSN, offer him/her a job and maybe even get bank account details to "setup direct deposit". Commented Jul 12, 2013 at 14:20

SSL provides several benefits not just data privacy. By presented a properly signed SSL certificate there are some assurances that the server your clients connect to actually is yours (let's assume CAs aren't being negligent).

SSL provides data integrity. For every string of text, whitepaper, image, patch, whatever, the user can have some assurance that the information they see is actually what you're presenting (let's assume your server hasn't been hacked).

The visual identifier of an SSL session in your browser provides a PR level indicator that your company takes itself seriously. That they want their message to be heard correctly. There is an implication that the company will also be just as careful with their client/customer data as well.

While it is obvious that any website that accepts sensitive information must be encrypted, there are some other benefits that can make it worthwhile.

Personally, I'm of the mindset that SSL encryption is cheap enough, at this point that there's almost no reason not to turn it on by default. At least then, if you change your business model and begin taking information online then you won't have to retrofit anything.


I'm a fan of SSL everywhere. You may not be transmitting anything that might be sensitive now, but you never know if that might change.

In my opinion, there really isn't any good reason NOT to use SSL.

With regards to below comments on free SSL certs, the EFF has launched their Let's Encrypt program, that provides trusted and free SSL certificates.

  • I agree, you can even get a free SSL cert from CACert.org and according to their wikipedia article their root certificate is distributed with most Linux distro's but not with windows though, so it will act as a "real"/verisign monopoly certificate if you are on Linux.
    – MyMichelle
    Commented Jul 13, 2013 at 17:11
  • Also agree. These days, there are few legitimate reasons not to just use SSL. In my experience, security flaws are often found in sites with mixed SSL and non-SSL configurations because of either a config error or soemething being accessible from the non-SSL site by mistake. When SSL represented significant processing overhead, it was worthwhile having content split between SSL and non-SSL. However, this is less justified and given you already havve sensitive info (job apps), SSL would make sense.
    – Tim X
    Commented Jul 18, 2013 at 22:36
  • 1
    @MyMichelle CACert is not trusted by anyone important, but StartCom offers free SSL certificates that work
    – kinokijuf
    Commented Mar 29, 2014 at 14:51
  • Added a link to the EFF Let's encrypt program which is also offering (soon) free SSL certificates.
    – Casey
    Commented Oct 26, 2015 at 19:11

Yes, your site should have SSL.

  • SSL and its certificates are not very expensive at this point in time. Sure you CAN buy very expensive certificates but the entry level is quite low
  • You are collecting personal information on the client side and transmitting it to the server (why should anyone in the middle be privy to that?)

You default should be "SSL" unless you have a strong reason otherwise (eg: no client data coming back, any data between server and client would be ok if published on the front page of the New York Times etc)


There is a huge misconception that SSL is some sort of firewall or something, this is simply not true. SSL is to protect from from Man-in-the-middle attacks or if gateway traffic is being monitored when the host or client are sending sensitive information.

The biggest risks you have are:

  • Your site information appearing to be modified if the client's connection is compromised
  • Clients resume being intercepted
  • Receiving the client's resume modified

I don't see this as being your problem.

SSL doesn't stop XSS or injection attacks, good programming does.

  • 2
    "I don't see this as being your problem." -- You don't think it's their problem if they miss out on potential hires? Or think that those items you listed simply won't happen regardless of whether that can (e.g., because the company is too small of a target)? Or do you mean something else?
    – apsillers
    Commented Jul 12, 2013 at 17:10
  • @apsillers Call me heartless, but Personally I wouldn't want to hire someone with a compromised connection, so I wouldn't be missing out on anything.
    – Dani
    Commented Jul 12, 2013 at 17:16
  • @dprogramz: How do you check your ISP/university/employer/hotels/coffee shops/... (assuming they use encrypted WiFi AND there is no ARP spoofing) for security breaches? Dealing with open connections is a fact of life (for example - my ISP is down so I need to use coffee shop to browse your website) and it is relatively safe if site's using SSL/TLS. Commented Jul 13, 2013 at 17:07

Not only should you implement HTTPS, but it should be on by default. This reminds me of a quote from the EFF that went something like this: "in an ideal world, every web request would be sent over SSL/TLS." Security and Privacy should be on by default. It cannot be optional. And for privacy to not be suspicious, everybody needs to do their part. Like others have already said, you are acquiring sensitive data (personal info), so be mindful of your users.


I don't think there's any point to having one if you're not transferring any sensitive information over it. Also if you're at the point where people will understand secured email then they will also understand that the site's mechanisms and the email's mechanisms can be wildly different. I don't expect anyone to even notice, honestly.

  • 1
    Not voting up because I believe that job applications are sensitive information.
    – Patrick M
    Commented Jul 12, 2013 at 19:39
  • 1
    You're making assumptions. MyMichelle specifically said "even though no "sensitive" or "important" data that needs to be encrypted will be sent or retrieved from our site?" I took the poster at their word and gave them advice relevant to that. You and I don't know what information they are collecting, and until we do its unfair to decide based on that.
    – Paarth
    Commented Jul 12, 2013 at 20:34
  • 1
    This answer shows confusion regarding secure email (which is an oxymoron anyway)
    – Tim X
    Commented Jul 18, 2013 at 22:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .