0

FIRST: I know HTTPS is HTTP + SSL. I am aware that SSL is the only true option for securely sending information on a connection over the Internet. My question pertains to a situation in which SSL is not the choice and encryption isn't necessary - but is desired anyway.

SECOND: This is not a duplicate. Questions such as How to send password securely via HTTP using Javascript in absence of HTTPS? describe the problems with other methods, but not specifically one could use as the next-best thing when encryption is employed for educational purposes.

As part of some research on Internet security outside of class, I want to create a website that uses user profiles and allows users to log in via password. This website does not take credit card information, will not hold sensitive personal information, and will not, in general, be a website where it's worth it to steal personal information. For the purposes of this question, I'll make up something and say the website just holds a person's favorite movies. For these reasons, I don't want to use SSL.

I do want, however, to use some other encryption. I know encryption isn't necessary, because no one in practice would try to steal the account for a website that just holds the info for someone's favorite movie. The purpose is purely educational, to see how secure the next-most secure option can be behind SSL. As stated above, I know SSL is the only true secure connection.

The question: Given the situation I've described, what are the options for providing a 'somewhat-secure' connection? Can a website use IPsec to secure the connection, and/or use something like Challenge-Response?

Thank you in advance.

EDIT: I need encryption for all traffic, not just login.

Community
  • 1
  • 1
  • Please clarify: Do you want **encryption** for all traffic, or do you just want a secure login without HTTPS? – Eugen Rieck May 08 '14 at 01:28
  • Ah. Good question. Encryption for all traffic. –  May 08 '14 at 01:30
  • 1
    You said yourself that the content is not sensitive, so why encrypt everything? It sounds like all you really need is to encrypt the user credentials during login, and standard HTTP already supports that via its `Authorization` and `WWW-Authenticate` headers. Use a secure auth scheme like NTLM or Kerberos, which both use challenge-response models. – Remy Lebeau May 08 '14 at 01:42
  • Good point. I don't have any particular good reason for choosing "encrypt all traffic" beyond curiosity at the response, since it seems like it would be the more difficult task of the two. –  May 08 '14 at 01:49

1 Answers1

0

You need a few building blocks:

  • You can not use classic form submits and HTTP-links in your site, but you must run all your requests through AJAX
  • Before sending your AJAX requests, you must encrypt the: This SO question gives you a good pointer on how to to that to talk to PHP
  • Before sending back your replies from PHP you must encrypt them, then decrypt the in JS

This works well, I use it quite regularily - it provides an easy alternative to some aspects of HTTPS (which I consider fundamentally broken)

Community
  • 1
  • 1
Eugen Rieck
  • 64,175
  • 10
  • 70
  • 92
  • 2
    Your technique is much more broken than HTTPS as there is no authentication step. – user207421 May 08 '14 at 02:02
  • @EJP - what hinders the OP from using the same method to send the login request? – Eugen Rieck May 08 '14 at 02:03
  • @EugenRieck EJP was talking not about login, but about authenticating the server. This is the cornerstone of SSL/TLS (as well as SSH and some other technologies). Without checking server's authenticity your scheme is subject to man-in-the-middle attacks and is broken trivially. – Eugene Mayevski 'Callback May 08 '14 at 05:38
  • @EugeneMayevski'EldoSCorp Which is why I said "easy alternative to **some aspects** of HTTPS". That said, the authentication of the server ist the most broken part in HTTPS, it relies on a chain of trust, that is not trustworthy and not verifyable. – Eugen Rieck May 08 '14 at 10:53
  • Authentication itself in SSL/TLS is neither broken nor unverifiable. Some particular configurations might be, but not all. And in your case you have a scheme broken by design. – Eugene Mayevski 'Callback May 08 '14 at 12:36
  • @EugeneMayevski'EldoSCorp 1. I just replaced the encryption part, not the authentication part - please elaborate, on how this is "broken by design" 2. That said, the authentication part of SSL relies on the trustworthyness of root certificates, that have many times been shown to be not trustworthy: Remember `Diginotar`, `Comodo` and friends? There are many indications that root certificates e.g. from Verisign are compromised by secret services around the world. Verification via compromised roots is no verification. – Eugen Rieck May 08 '14 at 12:45
  • Does anyone force you to use compromised roots? You can always take the same approach as in SSH - explicitly add the certificate of each host to the trusted certificates list and remove pre-installed trusted roots. – Eugene Mayevski 'Callback May 08 '14 at 15:13
  • @EugeneMayevski'EldoSCorp this is the part, where HTTPS becomes unusable: Before trusting HTTPS, you need to manually get the site certificate (outside of the system). If "don't use the chain of trust, it is broken, use single-site certs instead" is the best argument, HTTPS really is broken beyond hope of repair. – Eugen Rieck May 08 '14 at 18:24