I have configured my machine to use Dot1X user authentication with a RADIUS server, I want to inspect the data and the certificates exchanged between them but I only see encrypted data, have configured sslkeylogfile but it seems that it only collects the keys for the browser, not the EAP-TLS 1.2 connection,
Any ideas?
Related
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
For the purposes of secrecy and authenticity of communications I use SSL / TLS (https) with client certificate. If I log the entire SSL traffic on the server side, is the SSL log sufficient evidence that the communication between the server and the other side with client certificate was exactly as it is recorded in the log? At the beginning an asymmetric handshake is used but further communication continues with symmetric encryption. Symmetric encryption would not mind if one of the messages cannot be forged on the receiving side. As a server I know the symmetric key so it should be able for me to spoof one of the messages sent by the client, shouldn't it? What algorithm and what special settings shall I use, so that client could not say that he sent a different message than what I recorded in the log?
Logging anything (including data from SSL) does not proof the origin of the data. In theory you've could made up the data yourself. Even logging the complete SSL traffic including the necessary encryption key does not proof anything because in most cases this could have been made up too.
It might be acceptable as a proof if the whole SSL traffic is logged including the encryption key and if a client certificate was used for authentication (i.e. two-way SSL). The real client certificate owned by the client is a part you can not make up yourself. But there is still no guarantee that some judge would accept it as proof. And of course the client could try to deny that this is its own client certificate which was used.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I just recently set up SSL on my website's account creation page. I'm looking to expand this further to my entire site.
I had a question, though. How does SSL encryption actually work and protect data in transit? Furthermore, what methods are normally available to hackers to intercept data sent in plain-text over HTTP? I know there is "sniffing", but that is always the only method given, there is never any elaboration. Is there a way to examine the data being sent over HTTP and HTTPS? To compare and contrast?
HTTP is not encrypted in any way. Any network sniffer that can sniff the packets between the HTTP client and server (most network adapters support a promiscuous mode for this purpose) can view the HTTP data.
HTTPS data, on the other hand, is HTTP data that is encrypted with SSL/TLS. SSL/TLS encrypts outbound data before it hits the network, and decrypts inbound data after being leaves the network. There is no plain text on the network, so it doesn't matter if the packets are sniffed by a third-party. Without the encryption keys, the sniffed data is garbage. During the SSL/TLS handshake, the client and server negotiate encryption keys, certificates, etc with each other before any application data can then be exchanged. Data that is sent to the server is encrypted using the server's key, and data sent to the client is encrypted using the client's key. This ensures that encrypted data sent by the client can only be decrypted by the server, and vice versa.
About the only way to intercept and extract plain text from a SSL/TLS encrypted connection is with a man-in-the-middle attack. This means the SSL client connects to the MITM, and then the MITM connects to the SSL server, and funnels data back and forth between them. The MITM needs access to the network that the client or server are running on, and has to be able to reroute the client's connection to itself instead of the server. But if it can do that, the MITM can negotiate its own SSL/TLS connections with both parties so it has all of the necessary encryption information. It can then receive and decrypt the SSL client's sent data using the encryption keys it negotiated with the SSL client, then re-encrypt and pass that data to the SSL server using the encryption keys it negotiated with the SSL server. And vice versa. The SSL client and SSL server will not know they are talking to a MITM instead of each other, unless you use certificates so the SSL client and SSL server can verify each other's identity during the initial handshake. SSL/TLS does not require certificates, but they are good to use if you have them.
I know that certificates that are sent by the server cant be faked (still there is MD5 collisions but costy) but what about faking the client ..
in man in the middle attack:
cant we tell the server that we are the legitimate client and take data from that server manipulate it then encrypt it again with legitimate client public key ? how does the client be sure that the data came really from the server ?
in theory .. can we inject any data into the response sent by the server to the client ?..
How are you authenticating the client? SSL client certificates? Or some application level system (cookies etc)?
Here's what SSL does in a nutshell:
Negotiates a Diffie-Hellman shared session key between the two parties
Has the server sign the session key and send the result to the client. Once the client verifies this, the client knows there is no MITM, and the server is who they say they are.
If client certificates are enabled, has the client sign the session key and send the signature to the server. The server now knows there is no MITM and the client is who they say they are.
Encrypts all data in both directions using the shared session key
Typically when you use SSL you won't use client certificates. Strictly speaking, the server does not know if the connection is MITM'd. However, most clients will disconnect if the server certificate is bad. The server assumes that if the client pushes forward with the connection, there is no MITM. Even if Mallory, doing the MITM, chooses not to propagate the disconnect from the client, he has no new information now; all he's done is connected to the server himself. Without intercepting the client's session cookie or other authentication information (which is only sent by the client after verifying the connection is secure) the MITM is useless.
So in short, as long as one end or the other verifies the certificate of the other end before initiating any high-level communication of sensitive information, SSL is secure in both directions.
You're right -- without secure certificate authentication on the client and server there is an opening for a man in the middle attack.
SSL can be "secure both ways" if you use mutual authentication also called two-way SSL.
I configured SSL mechanism in tomcat 6 by generated certificate using java keytool with RSA algorithm and I’m able access the urls using the HTTPS.
Now I have few doubts
While communicating client with server (browser to server or server to browser), is Data also encrypted using 128 bit encryption?
If stand alone application is communicating with server do I get encrypted data only?
Please clarify my doubts. Thanks in advance
Yes, once the SSL connection has been negotiated (which is the first thing that happens), all data (client and server) is encrypted.
Any application communicating over an SSL-secured channel will have all its data encrypted and (because of certificate signing) it will be relatively confident that it's speaking with the actor it thinks it should be speaking with (ie, it will have protection against MITM attacks).
If you're connecting with an SSL-enabled client (whether that's a browser, libcurl, or something else) to whatever port you have configured for SSL, your entire communication path will be encrypted. If you try to connect with a non-SSL-enabled client to an HTTPS listener, you'll get a Bad Request error message like this:
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
If you're really concerned, try using something like Wireshark to view the communication between client and server.