I was wondering if there are any downsides to using HTTPS with HTTP Digest Authentication. I chose HTTP Digest because its fairly easy to incorporate for an api but its not the most secure because it uses MD5 and it is susceptible to Man in the middle attacks. Would combining HTTP Digest Authentication with HTTPS make a better solution or a bad one. I would greatly appreciate any advice. Thanks
Use of HTTP Digest authentication is definitely better with HTTPS as the encrypted tunnel is formed prior to sending the credentials. This (partially) negates the risk of MITM that basic auth and digest auth create.
Of course, if your system is built such that a client can accidentally hit an improper endpoint or still access it over HTTP (rather than just not listening on 80) then the credentials will still be transmitted insecurely.
Related
I am developing an online-shop based on a Telegram Bot, and I need to host it on a VPS. What are the dangers if I use a self-signed SSL certificate?
I found online that there's a MiTM attack threat, but I couldn't find a detailed explanation on how it can be avoided when using a self-signed SSL.
For example, will it help if all requests are sent to/from a URL of type: www.example.com/?
This is based on my reading of the Telegram Bot API.
There are two ways to control your bot, both of which involve "reasonably" secure protocols that are hard to man-in-the-middle (MITM). First, all communications with the Telegram server using the Bot API uses HTTPS. You must authenticate the Telegram server by doing a proper certificate chain validation. Telegram both authenticates you and identifies you by checking the token you supply in your HTTP request. This token was given to you when you created your bot and must remain a secret.
In addition, you may also elect to receive updates via a webhook. This basically involves you running an HTTPS server using a self-signed certificate. However, you provide your certificate to Telegram over a secure mutually authenticated connection when you setup the webhook, so this eliminates the MITM threat. The Telegram documentation suggests a method you can use to verify that the connection is coming from Telegram.
CAVEATS:
I've never implemented a Telegram Bot, so this is just based on reading the Docs.
Simply because it looks secure to me after 10 minutes of study doesn't make it so. Since this is a unique protocol within HTTPS I would want to see some expert analysis before I'd be confident.
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
Is possible to use Auth0 server over HTTP intead of HTTPS?
If yes, how to?
If not, why?
(I known the http is sniffeable)
It's not possible.
A secure transport layer is required on all of the communication flows used in the authorization protocols supported by Auth0: OAuth2, OIDC, SAML and WS-Federation. This is to ensure the security of items such as credentials, tokens, and personally identifiable information.
HTTPS is also required on mandatory for the administration Dashboard and every related service. Again, it wouldn't make sense to exchange information used to secure systems over an insecure protocol.
I see facebook sends cookies over http. How are they secure from hijacking? If I were to copy the cookie onto another computer would I be logged in?
You've just described Session Hijacking, and it is a real security issue. It can be avoided in a number of ways. The simplest way to secure the cookies, though, is to ensure they're encrypted over the wire by using HTTPS rather than HTTP.
Cookies sent over HTTP (port 80) are not secure as the HTTP protocol is not encrypted.
Cookies sent over HTTPS (port 443) are secure as HTTPS is encrypted.
So, if Facebook sends/receives cookies via HTTP, they can be stolen and used nefariously.
Cookies sent over HTTP are unsecure, those sent over HTTPS are a bit more secure than HTTP, however they can still be stolen since there are a few methods discovered lately to hack SSL. A complete writeup on session hijacking and all of the session hijacking attacks can be found here: http://cleverlogic.net/tutorials/session-hijacking-0. There is also a bit on preventing Session Hijacking.
What makes https more secure than http?
The short answer is that https communication between your browser and the server are encrypted. While http traffic is sent in plain text. This means that anyone who can listen to the traffic can read it - this would include usernames and passwords). It also verifies the server to which you are connecting.
That it is encrypted. Read: en.wikipedia.org/wiki/HTTP_Secure
Anything not over HTTPS can be read by anyone snooping on your network.
Im quoting:
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server.
More information on TLS:
The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. TLS provides RSA security with 1024 and 2048 bit strengths.
Also, HTTPS verifies that the site is who it claims to be, if the certificates are correct (signed by a known CA).
All traffic is encrypted. No one on your network can see what is going on (except for knowing where those packets are going to).
The identity of the remote server can be verified using certificates. So you also know that it really is your bank that you are talking to.
Optionally (and not in wide-spread use), the identity of the client can also be verified using certificates. This would allow for secure login to a site using chip cards instead of (or in addition to) passwords.
I want to be really pedantic, as I'm a security nerd :)
HTTPS uses SSL, and it's IETF-ratified cousin, TLS. SSL/TLS can offer four security services:
1) server authentication
2) channel encryption
3) channel tamper detection
4) client authentication
Usually you'll get server auth for free, but only if the host name and the common name in the server's SSL/TLS certificate match. If they don't match your browser will warn you. You usually get the channel defenses for free too, but that's only because the server and client negotiate to require such defenses. In theory, but rarely in practice, a server and client could agree to not use one or more of the channel defenses.
Finally, client authentication is when the server wants you to present a certificate (actually, to prove you have an associated private key) to verify you are you. Client authentication is rarely used.