If someone sniffs the network traffic, can he re-send the exact same encrypted request he sniffed (without tampering it) to the server? For example a request could activate some procedure on the server, so could he re-activate that procedure because he has the request content, even if it was on HTTPS?
This is known as a Replay Attack:
A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.
SSL/TLS inherently protects your connection against replay attacks, so anything over HTTPS is protected.
However, if there's a proxy server (possibly transparent) en-route with an SSL certificate trusted by your browser (such as in a corporate environment where root certs signed by the organisation are installed on each computer), then this would be able to replay HTTPS traffic.
Well the answer depends on who may attack your system:
If the user using your web page or application is the attacker the clear answer is YES, the request data is accessible.
If an local system admin has to considered as potential attacker the answer is YES.
If you are talking about an external attacker which does only have access to the encrypted data packets (e.g. the internet access provider) the answer is NO.
You can always redirect HTTPS traffic through a decrypting proxy which records all request and response data. The client only has to accept/install/trust the certificate of the proxy.
Related
I am familiar with SSL/TLS and its mechanism to protect data sent over HTTP between the browser and the web server. One of the issues identified by my security testing team is request tampering over SSL where they were able to modify the HTTP request payload of a POST request using man-in-the-middle attack. The browser obviously did show a certificate validity warning and it was ignored.
In my opinion, the application shouldn't handle or remediate such request tampering scenarios because SSL/TLS takes care of it. Server side validation of data that matches any client side validation should suffice to ensure that the HTTP payload is valid.
So my question is basically to confirm my understanding about this. Is request tampering using man-in-the-middle attack over SSL a valid security testing scenario? And should an application do any specific request encoding to protect from such attacks.
Yes, it is a valid testing scenario.
Depending on the threat model of your application, the application might implement Certificate Pinning, to mitigate that threat. With that, you can make sure that only a specific cert (or certs signed by a certain CA are trusted.
See this answer for reference.
I need to post three strings in a form from the site A to other site B which are hosted on the different servers.
Both sites use HTTPS connection.
My question is:
Are the three strings encrypted(using site B's HTTPS connection) during transmission across the network? I feel the three strings doesn't be encrypted, but I don't know the main reasons.
When using HTTPS, all form data, indeed all data, passed between client and server is encrypted during transmission.
HTTPS is a secure channel between the client (browser) and the server that terminates HTTPS (usually the web server, but it can also be a load balancer for instance). Anything that is sent between the client and the server over HTTPS is encrypted, its integrity is protected and also the server is authenticated (but the client is not). It means a man in the middle attacker can not read the traffic, cannot modify it (by doing things like reordering packets), and also an attacker cannot impersonate the server (however, lack of client authentication means the attacker can impersonate the client unless authentication is implemented in the application).
All of this implies that any traffic downloaded from site A over HTTPS is secure between site A and the client, and then any traffic sent from the client to site B is again secure between the client and site B. However, in both cases the client terminates HTTPS connections, meaning the client can read or tamper with the data, ie. you cannot guarantee on server B that a potentially malicious user having access to the client has not changed the data downloaded from server A before passing it to server B.
Regardless of this, if you only take the connection from the client to server B, that is of course encrypted and secure.
It's worth to note that due to the way the network stack (TCP/IP) works, some information is leaked though. For example a man in the middle attacker will get to know endpoint IP addresses, and also the approximate amount of data transferred in most cases. However, he will have no information from the HTTP protocol (request or response headers, bodies, etc.)
I have a simple question which I can not find a simple answer to, probably I am missing something or I don t know about how some networking concept works. And I want to know what I don t know.
Simply, the question is while eavesdropping is possible, how can server know the request is coming from client, not the eavesdropping hacker.
Scenario :
Whatever the security policy I am having, I should send something to client. It might be a asymmetric encrypted token or sth. Client has no private key, so that whatever client is able to do, send etc, a hacker can do, send too.
What might be the logic behind securing a web application. There should be something secret which only client knows.
Btw I am learning about JWT and this is the first time I am learning about auth. But this simple question is something I am still unable to find an answer to.
How can a server know the request is coming from client, not an
eavesdropping hacker?
It doesn't.
It is up to the client to verify that the server is the one it expects to be talking to. It's called Public Key Infrastructure.
TLS/SSL can be used so the connection is over HTTPS - note it does not have to be Diffie Hellman, there are other key exchange mechanisms such as RSA.
Imagine the following scenario.
Client --> HTTPS --> example.com
The client will do a DNS lookup for example.com, and say 203.0.113.10 is returned. The client will connect to 203.0.113.10 over HTTPS, and the initial part of the connection is called the handshaking process. Here the client checks that the domain it is thinking of connecting to, example.com, has a certificate signed by a trusted Certificate Authority with the subject set to "example.com". This will prevent the following from happening:
Client --> HTTPS --> Attacker (fake example.com)
For example, if the attacker had taken over a DNS server and changed example.com to point to him (198.51.100.200).
This attack is prevented because the attacker cannot prove ownership of example.com to a Certificate Authority and therefore won't be able to get their certificate signed in order to prove to clients that their server is trusted.
HTTPS also encrypts the connection, and exchanges keys in a secure manner. This ensures that an already established connection cannot be read.
So once a connection is established, and a user logs in, the server will send a session token to the client, which can be in the form of a JWT. If this is a cookie and the Secure Flag is set, this can only be transmitted over an HTTPS connection. This is how the server knows that it hasn't been intercepted because the client has verified the server and has encrypted the data in transit to it using unique keys agreed by both parties.
Client --> HTTPS --> Attacker (fake example.com) --> HTTPS --> example.com
Is also not possible (active Man-In-The-Middle), which shows the situation in your original question where somebody intercepts communications and passes the JWT to the real server, observing the private data in transit. This, however is if plain HTTP is used (no SSL/TLS):
Client --> HTTP --> Attacker (fake example.com) --> HTTP --> example.com
Indeed, when establishing a new connection there is nothing only the client knows.
That is why the
Diffie–Hellman key exchange
and similar methods were invented.
They work by sending questions and answers between server and client.
Doing this many times with (actually) not so complex mathematical methods the client and server can share a key wich only they know, even if a third party intercepted the traffic.
I cannot fully explain the concept but I can recommend this StackExchange question wich will provide a good overview of the topic.
Edit: I only just now heard of JWT so this answer might be completely out of context.
Look up Diffie-Hellman and SSL/TLS encryption. Here is something to get you started.
https://blog.hartleybrody.com/https-certificates/
The short answer is when a client initiates a connection to a server they share a secret key that is not exposed publicly. The thing is, the client needs to be making that initial connection to the server it thinks it is wanting to connect to.
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
I am developing a Node.js app based on the Express framework. On the backend, I need to have servers talk to each other (ie. Server 1 make a request of Server 2).
Is it OK to forego a DNS A-Record and just use the IP address of the server?
In that case, how do I authenticate the server and "client" (aka server). I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
Using a IP might be more secure then DNS (e.g. no DNS spoofing), but it still allows ARP spoofing, e.g. some other computer claims to have this IP. And in case both computers are not in the same network there are also ways to hijack requests in routers etc.
The secure cookie is nothing else as a shared secret. And contrary to public key based authentication (e.g. using certificates) shared secrets have the disadvantage that you need to distribute them in a secure way so that nobody else gets access to them.
I don't think that your idea is easier to handle than SSL with certificates, so I don't see an advantage of making your own secure protocols. History tells us, that such homegrown protocols mostly provide worse security than established solutions.
If you don't care about security (these hosts are on your network, in which you have trust), don't bother with the homebaked cookies.
If you do care about security get (or generate your own) certificate and use SSL.
I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
This is not secure at all! Anybody situated on an appropriate network between the client and server can see that "secure cookie", as well as any subsequent communications. This would allow them to reuse that cookie themselves to impersonate either the client or server, and would expose any sensitive information sent in the exchange.
Use SSL. It has already solved all of these problems, and more.
I'm reading a book on WCF and author debates about pros of using message-level security over using transport-level security. Anyways, I can't find any logic in author's arguments
One limitation of transport
security is that it relies on every
“step” and participant in the network
path having consistently configured
security. In other words, if a message
must travel through an intermediary
before reaching its destination, there
is no way to ensure that transport
security has been enabled for the step
after the intermediary (unless that
interme- diary is fully controlled by
the original service provider). If
that security is not faithfully
reproduced, the data may be
compromised downstream.
Message security focuses on ensuring the integrity and privacy of
individ- ual messages, without regard
for the network. Through mechanisms
such as encryption and signing via
public and private keys, the message
will be protected even if sent over an
unprotected transport (such as plain
HTTP).
a)
If that security is not faithfully
reproduced, the data may be
compromised downstream.
True, but assuming two systems communicating use SSL and thus certificates, then the data they exchange can't be decrypted by intermediary, but instead it can only be altered, which the receiver will notice and thus reject the packet?!
b) Anyways, as far as I understand the above quote, it is implying that if two systems establish a SSL connection, and if intermediary system S has SSL enabled and if S is also owned by a hacker, then S ( aka hacker ) won't be able to intercept SSL traffic travelling through it? But if S doesn't have SSL enabled, then hacker will be able to intercept SSL traffic? That doesn't make sense!
c)
Message security focuses on ensuring the integrity and privacy of individ-
ual messages, without regard for the network. Through mechanisms such
as encryption and signing via public and private keys, the message will be
protected even if sent over an unprotected transport (such as plain HTTP).
This doesn't make sense, since transport-level security also can use encryption and certificates, so why would using private/public keys at message-level be more secure than using them at transport-level? Namelly, if intermediary is able to intercept SSL traffic, why wouldn't it also be able to intercept messages secured via message-level private/public keys?
thank you
Consider the case of SSL interception.
Generally, if you have an SSL encrypted connection to a server, you can trust that you "really are* connected to that server, and that the server's owners have identified themselves unambiguously to a mutually trusted third party, like Verisign, Entrust, or Thawte (by presenting credentials identifying their name, address, contact information, ability to do business, etc., and receiving a certificate countersigned by the third party's signature). Using SSL, this certificate is an assurance to the end user that traffic between the user's browser (client) and the server's SSL endpoint (which may not be the server itself, but some switch, router, or load-balancer where the SSL certificate is installed) is secure. Anyone intercepting that traffic gets gobbledygook and if they tamper with it in any way, then the traffic is rejected by the server.
But SSL interception is becoming common in many companies. With SSL interception, you "ask" for an HTTPS connection to (for example) www.google.com, the company's switch/router/proxy hands you a valid certificate naming www.google.com as the endpoint (so your browser doesn't complain about a name mismatch), but instead of being countersigned by a mutually trusted third party, it is countersigned by their own certificate authority (operating somewhere in the company), which also happens to be trusted by your browser (since it's in your trusted root CA list which the company has control over).
The company's proxy then establishes a separate SSL-encrypted connection to your target site (in this example, www.google.com), but the proxy/switch/router in the middle is now capable of logging all of your traffic.
You still see a lock icon in your browser, since the traffic is encrypted up to your company's inner SSL endpoint using their own certificate, and the traffic is re-encrypted from that endpoint to your final destination using the destination's SSL certificate, but the man in the middle (the proxy/router/switch) can now log, redirect, or even tamper with all of your traffic.
Message-level encryption would guarantee that the message remains encrypted, even during these intermediate "hops" where the traffic itself is decrypted.
Load-balancing is another good example, because the SSL certificate is generally installed on the load balancer, which represents the SSL endpoint. The load balancer is then responsible for deciding which physical machine to send the now-decrypted traffic to for processing. Your messages may go through several "hops" like this before it finally reaches the service endpoint that can understand and process the message.
I think I see what he's getting at. Say like this:
Web client ---> Presentation web server ---> web service call to database
In this case you're depending on the middle server encrypting the data again before it gets to the database. If the message was encrypted instead, only the back end would know how to read it, so the middle doesn't matter.