I was trying to make a website that require the user to log in to do something, but I want to know the advantage and disadvantage from HTTP and HTTPS first.
I was using a program called Fiddler that allowed you to logs all HTTP(s) traffic between your computer and the Internet
if I try to log in with the program on, I could see the username and the password that I used to log in to the website, even if it's HTTP or HTTPS using fiddler
so what's the use of HTTPS compared with HTTP?
This is what I am thinking.
The browser is supposed to enscrypt the password using the server's public key right? Then the server will descript it with the private key.
But fiddler doesn't know the server's private key. So how can it sees the plain password?
Am I wrong?
In HTTPS communication is sent over an encrypted channel, while HTTP is sent in plain-text. Most importantly his means that a 3rd party can't read information sent between the server and the browser just by sniffing network traffic, but it has other uses as well, such as ensuring that the server is who it says it is and you are who you say you are with certificates.
Fiddler2 is only able to decipher the traffic with the user's cooperation: the certificates Fiddler presents to the client are only trusted by the browser if you configure your Operating System to trust Fiddler's root certificate.
Related
Our web application has a button that is supposed to send data to a server on the local network that in turn prints something on a printer.
So far it was easy: The button triggered an AJAX POST request to http://printerserver/print.php with a token, that page connected to the web application to verify the token and get the data to print and then printed.
However, we are now delivering our web application via HTTPs (and I would rather not go back to HTTP for this) and newer versions of Chrome and Firefox don't make the request to the HTTP address anymore, they don't even send the request to check CORS headers.
Now, what is a modern alternative to the cross-protocol XHR? Do Websockets suffer from the same problem? (A Google search did not make clear what is the current state here.) Can I use TCP Sockets already? I would rather not switch to GET requests either, because the action is not idempotent and it might have practical implications with preloading and caching.
I can change the application on the printerserver in any way (so I could replace it with NodeJS or something) but I cannot change the users' browsers (to trust a self-signed certificate for printerserver for example).
You could store the print requests on the webserver in a queue and make the printserver periodically poll for requests to print.
If that isn't possible I would setup a tunnel or VPN between the webserver and printserver networks. That way you can make the print request from the webserver on the server-side instead of the client. If you use curl, there are flags to ignore invalid SSL certificates etc. (I still suspect it's nicer to introduce a queue anyway, so the print requests aren't blocking).
If the webserver can make an ssh connection to something on the network where the printserver is on, you could do something like: ssh params user#host some curl command here.
Third option I can think of, if printserver can bind to for example a subdomain of the webserver domain, like: print.somedomain.com, you may be able to make it trusted by the somedomain.com certificate, IIRC you have to create a CSR (Certificate Signing Request) from the printserver certificate, and sign it with the somedomain.com certificate. Perhaps it doesn't even need to be a subdomain for this per se, but maybe that's a requirement for the browser to do it client-side.
The easiest way is to add a route to the webapp that does nothing more than relay the request to the print server. So make your AJAX POST request to https://myapp.com/print, and the server-side code powering that makes a request to http://printerserver/print.php, with the exact same POST content it received itself. As #dnozay said, this is commonly called a reverse proxy. Yes, to do that you'll have to reconfigure your printserver to accept (authenticated) requests from the webserver.
Alternatively, you could switch the printserver to https and directly call it from the client.
Note that an insecure (http) web-socket connection on a secure (https) page probably won't work either. And for good reason: generally it's a bad idea to mislead people by making insecure connections from what appears to them to be a secure page.
The server hosting the https webapp can reverse proxy the print server,
but since the printer is local to the user, this may not work.
The print server should have the correct CORS headers
Access-Control-Allow-Origin: *
or:
Access-Control-Allow-Origin: https://www.example.com
However there are pitfalls with using the wildcard.
From what I understand from the question, printserver is not accessible from the web application so the reverse proxy solution won't work here.
You are restricted from making requests from the browser to the printserver by cross-origin-policy.
If wish to communicate with the printserver from an HTTPS page you will need the printserver to expose print.php as HTTPS too.
You could create a DNS A record as a subdomain of your web application that resolves to the internal address of your printserver.
With those steps in place you should be able to update your printserver page to respond with permissive CORS headers which the browser should then respect. I don't think the browser will even issue CORS requests across different protocol schemes (HTTPS vs HTTP) or to internal domains, without a TLD.
Can HTTPS request be replayed using Fiddler/TamperData, probably due to poor handling of login process? Once I logout of my system (https), I am able to login back using replay.
Simon Buchan has already mentioned that HTTPS cannot be replayed.
Ref: https://stackoverflow.com/a/2770133/1502619
If replay logs me in, does that mean that my login doesn't handle replay attack or is it that I am not logging out correctly?
Simon Buchan notes (correctly) that a client cannot send exactly the same encrypted bytes to the HTTPS server and have it accept them as valid; one of the protections HTTPS provides is protection against that sort of "blind" replay.
What Fiddler & TamperData do isn't the same thing-- these tools start with the the same unencrypted bytes (e.g. your username and password) and establish a new HTTPS connection to the server and then send the HTTPS request to the server again on that new connection.
So, it's a replay of the same HTTPS request, but not a replay of the same raw bytes.
There's no practical way to prevent a tool with access to the unencrypted data (like Fiddler has) from logging into your site using that information.
This question tries to look into whether doing HTTPS log in is very important for any website.
Is it true that for many websites, if the login is done through HTTP but not HTTPS, then anybody can pretty much see the userID and password easily along the internet highway (or by looking between a router and the internet connection in an Internet Cafe)?
If so... do popular frameworks actually use HTTPS by default (or at least as an option), such as Rails 2.3.5 or Django, CakePHP, or .Net?
Yes, any machine on the pathway (that the packets pass through) can just examine the contents of the those packets. All it takes is a capturing proxy or a promiscuous mode network card with something like WireShark. Assuming that the passwords aren't encrypted in some other way (at a higher level), they will be visible.
I can't answer the second part of your question since I have no knowledge of those particular products but I would say that the inability to use secure sockets would pretty much make them useless.
Pax is right about passwords that aren't otherwise encrypted being visible.
Still, most sites don't use SSL still, and it does put the users at a certain degree of risk when accessing sites from public wifi.
HTTPS isn't a framework level option, it would be something you'd do when you set up the webserver. If you were to use an apache configuration for instance, you would open it up to a properly configured https, close http and install a certification. The framework wouldn't have a direct influence on that portion of the release.
If the user credentials are submitted via an HTML webform without HTTPS, then it is unsecure, the data is submitted in plain text. However, if the website uses HTTP authentication instead, then the server can send back a 401 reply (or 407 for proxies) to any request that does not provide valid credentials. 401/407 is the server's way to ask for credentials, and the reply provides a list of authentication schemes (Digest, NTLM, Negotiate, etc) that the server supports, which are usually more secure by themselves. The client/browser sends the same request again with the necessariy credentials in one of the schemes, then the server either sends the requested data, or sends another 401/407 reply if the credentials are rejected.
How does the browser figure out the destination in an HTTPS connection? All the headers are encrypted..
Update:No this is not a homework.. my name is student because I'll always be learning in this HUGE awesome field
When a browser views an url like https://www.gmail.com/ first thing your browser does is resolves www.gmail.com to 72.14.213.19.
Next your browser opens up a TCP connection to 72.14.213.19 on port 443.
The browser & server before ANY headers are transmitted negotiate a public key encryption scheme (RSA) based on the SSL Certificate that is digitally signed.
In this process the browser checks the certificate authenticity before communicating.
Once this trust between client & server has been established, the client now can encrypt the headers in a way the server can decrypt. It proceeds to make the HTTP request inside the SSL Tunnel.
The server decrypts the message, serves the request and encrypts it in a way that that particular client can decrypt.
The browser then decrypts the response, reads the headers and makes decisions about how to proceed from there.
This has been an overview of an HTTPS connection event. :D
The string containing https: that you typed in the browser is what the browser uses. That is not encrypted,
Probably more than you'd ever want or need to know about the The First Few Milliseconds of an HTTPS Connection I'd go into more detail explaining stuff if your username wasn't student, and this wasn't likely homework.
I am writing a little app similar to omegle. I have a http server written in Java and a client which is a html document. The main way of communication is by http requests (long polling).
I've implemented some sort of security by using the https protocol and I have a securityid for every client that connects to the server. When the client connects, the server gives it a securityid which the client must always send back when it wants a request.
I am afraid of the man in the middle attack here, do you have any suggestions how I could protect the app from such an attack.
Note that this app is build for theoretical purposes, it won't be ever used for practical reasons so your solutions don't have to be necessarily practical.
HTTPS does not only do encryption, but also authentication of the server. When a client connects, the server shows it has a valid and trustable certificate for its domain. This certificate can not simply be spoofed or replayed by a man-in-the-middle.
Simply enabling HTTPS is not good enough because the web brings too many complications.
For one thing, make sure you set the secure flag on the cookies, or else they can be stolen.
It's also a good idea to ensure users only access the site via typing https://<yourdomain> in the address bar, this is the only way to ensure an HTTPS session is made with a valid certificate. When you type https://<yourdomain>, the browser will refuse to let you on the site unless the server provides a valid certificate for <yourdomain>.
If you just type <yourdomain> without https:// in front, the browser wont care what happens. This has two implications I can think of off the top of my head:
The attacker redirects to some unicode domain with a similar name (ie: looks the same but has a different binary string and is thus a different domain) and then the attacker provides a valid certificate for that domain (since he owns it), the user probably wouldn't notice this...
The attacker could emulate the server but without HTTPS, he would make his own secured connection to the real server and become a cleartext proxy between you and the server, he can now capture all your traffic and do anything he wants because he owns your session.