I would like to build a user management system.
I think it's not secure to send user's password from browsers to servers over HTTP.
But I'm not sure if it's secure to send message to servers over HTTPS.
Whether the password can be attack if using HTTPS
Thanks
Related
My question is If I am hosting my website in HTTPS connection then could the cookie still be potentially stolen by an attacker to perform man in the middle attack?
In an HTTP connection, the attacker might intercept the cookie and can hijack a victim's session. So if the attacker can carry out a man in the middle attack, he can force the victim to make an http request and steal the cookie.
So does this risk is still there in the HTTPS connection? Or how can I make it more secure so that the attacker cannot steal the cookie?
The answer is YES.
Not sure if I am explaining this well enough.
But take a look at : https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
On an extra note:-
The cookie will reside on the user end and HTTPS just specifies that the connection that will be used between the two ends will be encrypted and an SSL certificate is used.
SSL certificates are what enable websites to move from HTTP to HTTPS, which is more secure. An SSL certificate is a data file hosted in a website's origin server. SSL certificates make SSL/TLS encryption possible, and they contain the website's public key and the website's identity, along with related information.
Or how can I make it more secure so that the attacker cannot steal the
cookie?
You must declare that on web.config using the requireSSL to force cookie only on secure connections
<httpCookies domain="domain.com" requireSSL="true"/>
more to read : Can some hacker steal a web browser cookie from a user and login with that name on a web site?
I'm developing an API that receives HTTP requests from the Internet. One of the problems I'm facing is how to authenticate those requests in order to know that they are actually coming from a specific IP address.
I have read the X-Forwarded-For header is not safe at all
RSA does not prevent Man in the Middle
What I'm doing is: given an id and a password, both parameters are sent in each request so the system can validate the request, but I think it's not the best option at all.
Any ideas?
Thank you!
Given that it's truly the IP address that you're needing to authenticate, and not any sort of user, then HTTP is too high on the networking stack. You need something like IPSec or WireGuard to authenticate IP addresses.
I suggest to redirect user to authenticate on HTTPS server that generates a token for him and then with that token request the infos on the HTTP server, so even a man in the middle can obtain current session and when the user logout it is useless.
And then you can even validate the IP from login on HTTPS on each HTTP request.
Edit: I think the whole process is explained really well here
I could find any quick answer on google. Most probably the answer lies somewhere in RFC docs on http or https however I just couldn't (too time consuming ) get those information.
So here is the question:
Is the content of a webpage served through HTTP signed digitally by the server ? Same question for HTTPS.
If yes, how does it work correctly when using a proxy ? In my opinion the proxy could tamper the data, sign the tampered data with it's own private key, and claim that the corresponding proxy's public key is actually the genuine public key of the original server ? I am assuming that the client can't check the original server's public key, because there is a proxy which could lie.
I am sorry if this is a dump question and easy searchable on the internet, but every answer I found posed some doubts to me.
Thanks for your help :)
Content sent via HTTPS is encrypted, clients verify the authenticity of the host certificates with whom they are communicating. The server uses a TLS/SSL key/certificate which is signed by certificate authorities (CA) The CAs make sure that they only sign the certificates of the rightful owners of a domain. The certificates of the CAs them-self are installed in you browser/OS. By using these pre-installed certificates, the browser can check if the key used by the remote server is signed by a trusted CA.
A man-in-the-middle does not have the original key, nor another key signed by a CA for the domain in question. Therefore, a man-in-the-middle cannot modify the content without breaking HTTPS.
On the other hand, if you want to use a proxy to cache requests, the proxy can terminate the HTTPS connections. This means the proxy has its own connection to the server and verifies the certificates. In order to secure the connection to the client, the proxy acts as a CA and uses a HTTPS connection with self-signed certificates. To avoid that your browser complains about an insecure connection, you need to install the proxies own CA certificate.
HTTP content is not signed and can be tampered with.
Edit 2018-06-15:
I wasn't really precise with the term "signed" here. The server does not actually sign the content it sends. This means if you store the responses from the server, you cannot prove that they came from that server, in other words: standard TLS dose not provide non-repudiation. However, the authenticity of the server is established during the handshake. The client encrypts a master-key with the servers public key. Only servers in possession of the private key can decrypt the master-key and derive session keys from them.
CAs, on the other hand, actually sign the certificates. A CA cannot validly deny that it signed for the authenticity of a server certificate.
I'm trying to understand how to send encrypted email from an ASP.NET application using an SMTP server set up on IIS. Apologies in advance if I'm not being clear - I'm fundamentally a programmer and my understanding of email is limited.
I know that the SMTP server can be configured to insist on TLS/SSL encryption. What I'm not clear about is how this works with the EnableSsl property of System.Net.Mail.SmtpClient() and the implications when sending to recipients which don't support encryption.
My goal is to ensure that emails sent to certain recipients are always encrypted, but I don't want emails to fail when sent to other recipients whose receiving SMTP servers don't support encrypted messages.
Is it possible therefore to use SSL conditionally in my scenario based on the intended recipient?
Usually mail is delivered to a mail server local to the sender, i.e. your "SMTP server set up on IIS". This mail server then looks up which servers are responsible for the recipients domain and forwards your mail to these servers.
While you can control how the connection is done between your application and your SMTP server (i.e. TLS or not) you have no control how this mail is forwarded from there on. But modern mail servers typically use TLS if the remote mail server offers support for it and fall back if TLS is not supported by the remote server.
I plan to run the logged-in portion of my app in HTTPS, starting with from the log-in screen. Once the user is logged-in and continues his session entirely in HTTPS, how could a MITM attack be performed? Isn't this kind of attack dependent on figuring out what the two parties are saying?
I'm using asp.net with WCF services, and later will port to Azure.
Thanks.
If your login session is encrypted with HTTPS, then you're secure against MITM attacks. The client will send data to the server encrypted using the server's public key, which can only be decrypted with the server's private key. The client and server will then use this secure channel to agree on a secret key to use for their communication.
The MITM attacker cannot get at the private key because it's private. They can't present a certificate for the target domain because certificates can only be obtained from a CA, and (theoretically) the CAs your browser trusts won't sign a certificate for a domain unless they prove they own it. They can't get at the session key, so a MITM attack is impossible.