From my understanding, each browser implement tls/ssl themself, which mean when user open a https website from a browser, the browser is responsible for encrypt the request.
So is it possible to make a browser or any other type of client that doesn't implement tls/ssl and therefore will make https without encryption? And if yes, then how ?
... client that doesn't implement tls/ssl and therefore will make https without encryption?
HTTPS is HTTP inside a TLS connection. This means a client which does not implement SSL/TLS will not be able to make a HTTPS connection in the first place by the very definition of what HTTPS is.
It might in theory be possible though that TLS is used without encryption, i.e. only with authentication and integrity check. Up to TLS version 1.2 there were the NULL ciphers which made this possible. In practice no sane server will implement this. If the client still tries to use such cipher the TLS handshake will fail since there is no common cipher between client and server.
See also Unencrypted SSL protocol?.
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.
I'm using mod_auth_basic to restrict access to an SSL folder, is the password transmitted as cleartext?
Do I need to use mod_auth_digest?
Depends on what you mean by "as cleartext". In the HTTP basic authentication exchange, passwords are sent as cleartext (encoded as base64). But the whole exchange is tunneled through the encrypted SSL connection, so you can't see them by observing the traffic. (Unless you've successfully compromised the SSL connection itself and can see all the traffic.) When doing basic auth through HTTPS/SSL, the server at the other end can still see your passwords as cleartext, but it's sufficient to protect against man-in-the-middle eavesdropping.
I'm using mod_auth_basic to restrict access to an SSL folder, is the password transmitted as cleartext?
Yes. Its transmitted in the clear within the SSL/TLS tunnel.
Do I need to use mod_auth_digest?
That's usually a problem, too.
The problem is that anyone that answers with a certificate is accepted. More correctly, the tunnel lacks "channel binding", where app authentication is part of the channel setup. So if someone intercepts the communication (i.e., proxy) or impersonates the up the server (phishing), then you send him/her password or MD5(password).
Its better to use a SSL/TLS protocol like TLS-SRP or TLS-PSK. Each use shared secrets like passwords, and each properly bind the channel. And both don't do dumb things like put the password on the wire in the plain text.
You can read more about these problems and solutions in Peter Gutmann's Enginerring Security.
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 am trying to understand what's the actual difference between SSL and Kerberos authentications, and why sometimes I have both SSL traffic and Kerberos.
Or does Kerberos use SSL in any way?
Anyone could help?
Thank you!
SSL uses public key cryptography:
You (or your browser) has a public/private keypair
The server has a public/private key as well
You generate a symmetric session key
You encrypt with the server's public key and send this encrypted session key to the server.
The server decrypts the encrypted session key with its private key.
You and the server begin communicating using the symmetric session key (basically because symmetric keys are faster).
Kerberos does not use public key cryptography. It uses a trusted 3rd party. Here's a sketch:
You both (server and client) prove your identity to a trusted 3rd party (via a secret).
When you want to use the server, you check and see that the server is trustworthy. Meanwhile, the server checks to see that you are trustworthy. Now, mutually assured of each others' identity. You can communicate with the server.
2
While Kerberos and SSL are both protocols, Kerberos is an authentication protocol, but SSL is an encryption protocol. Kerberos usually uses UDP, SSL uses (most of the time) TCP. SSL authentication is usually done by checking the server's and the client's RSA or ECDSA keys embedded in something called X.509 certificates. You're authenticated by your certificate and the corresponding key. With Kerberos, you can be authenticated by your password, or some other way. Windows uses Kerberos for example, when used in domain.
Keep in mind: Recent versions of SSL are called TLS for Transport Layer Security.
To put simply, Kerberos is a protocol for establishing mutual identity trust, or authentication, for a client and a server, via a trusted third-party, whereas SSL ensures authentication of the server alone, and only if its public key has already been established as trustworthy via another channel. Both provides secure communication between the server and client.
More formally (but without getting into mathematical proofs), given a client C, server S, and a third-party T which both C and S trust:
After Kerbeos authentication, it is established that:
C believes S is who it intended to contact
S believes C is who it claims to be
C believes that it has a secure connection to S
C believes that S believes it has a secure connection to C
S believes that it has a secure connection to C
S believes that C believes it has a secure connection to S
SSL, on the other hand, only establishes that:
C believes S is who it intended to contact
C believes it has a secure connection to S
S believes it has a secure connection to C
Clearly, Kerberos establishes a stronger, more complete trust relationship.
Additionally, to establish the identity of S over SSL, C needs prior knowledge about S, or an external way to confirm this trust. For most people's everyday use, this comes in the form of Root Certificates, and caching of S's certificate for cross-referencing in the future.
Without this prior knowledge, SSL is susceptible to man-in-the-middle attack, where a third-party is able to pretend to be S to C by relaying communication between them using 2 separate secure channels to C and S. To compromise a Kerberos authentication, the eavesdropper must masquerade as T to both S and C. Note, however, that the set of trusts is still unbroken according to the goal of Kerberos, as the end-state is still correct according to the precondition "C and S trusts T".
Finally, as it has been pointed out in a comment, Kerberos can be and has been extended to use SSL-like mechanism for establishing the initial secure connection between C and T.
In short:
Kerberos usually does not encrypt transferring data, but SSL and TLS do.
"there are no standard APIs for accessing these messages. As of
Windows Vista, Microsoft does not provide a mechanism for user
applications to produce KRB_PRIV or KRB_SAFE messages." - from
http://www.kerberos.org/software/appskerberos.pdf
In opposite, SSL and TLS usually do not transfer and proof Yours Windows domain login name to the server, but Kerberos does.
A short answer: SSL and Kerberos both use encryption but SSL uses a key that is unchanged during a session while Kerberos uses several keys for encrypting the communication between a client and a client.
In SSL, encryption is dealt with directly by the two ends of communication while in Kerberos, the encryption key is provided by a third party - some kind of intermediate - between the client and the server.
From http://web.mit.edu/kerberos/:
Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.
Meanwhile:
SSL is used for establishing server<-->server authentication via public key encryption.
From https://www.eldos.com/security/articles/7240.php?page=all,
Kerberos and TLS are not the things to compare. Their have different objectives and different methods. In the beginning of our article we mentioned the frequently asked questions like “which is better” and “what to choose”. The former is not a question at all: nothing is better and everything is good if you use it in a right way. The latter question is worth a serious consideration: what to choose depends on what you have and what you want.
If you want to secure your communications in a sense that nobody can read it or tamper it, perhaps the right choice is to use TLS or some other protocols based on it. A good example of TLS usage for securing World Wide Web traffic carried by HTTP is to use HTTPS. For secure file transferring you may use FTPS, and take into account that SMTP (though it stands for a “simple” mail transfer protocol, not “secure”) is also may be protected with TLS.
On the other hand, if you need to manage user access to services, you may want to use Kerberos. Imagine, for example, that you have several servers like Web server, FTP, SMTP and SQL servers, and optionally something else, everything on one host. Some clients are allowed to use SMTP and HTTP, but not allowed to use FTP, others may use FTP but don’t have access to your databases. This is exactly the situation when Kerberos is coming to use, you just have to describe user rights and your administrative policy in Authentication Server.
SSL authentication uses certifiactes to verify youself to server whereas Kerberos works entirely different.
SSL can be imported manually and added as per configurations in client and host manually.
Whereas kerberos is authentication where no password are transmitted over network. Here kerberos KDC server doesn't need to communicate with any service or host to verify the client. Client uses principle stored in kerberos to communicate with kerberos server. In return kerberos server provides ticket using keytab of other server stored beforehand. In the other server, the client provides the ticket and services matches the ticket with their own keytab and verify the client.
Simply put,
SSL is to encrypt the data so that the data cannot be understood by someone who is trying to steal it out in the network.
Kerberos is a network authentication protocol which helps in authenticating a client to talk to server without sharing any password/token during the time of the request.