I just started working on TLS/SSL(Secure Sockets Layer) related projects.
I happen to read a lot of documents related to SSL for getting comfortable for the project and at some point, it struck me that "While the client and server is connected for communications after the handshake, it said that a secure channel is created between the client and the server for all the communications of a session".
My doubt is, whether the secure channel created between the client and server itself is encrypted and the data transferred through that secure channel is plain text? or the channel is secure but not encrypted and only the data sent through that secure channel is encrypted?"
Some say that "SSL is an encrypted secure channel" and others say "Secure channel is created and the data is encrypted" which puts me in the situation to post this question
I read lot of documents to get clarified but the more i read, the more confused i am.
try to see it like this:
whenever you create a secure channel in this type of context, you create 2 endpoints...
whatever you stuff into the one endpoint comes out of the other ... what you put in may be plain text and it will come out as plain text ...
but what happens between the two endpoints ... that is subject of the actual protocol ... in this context something like "SSL is an encrypted secure channel" or "Secure channel is created and the data is encrypted" just describes features of the protocol, meaning that the stuff that happens between the two endpoints is ... encrypted ... secured against replay ... secured against unnoticed modification ... etc
if you have a setup like this:
SENDER -> X -> SSL Endpoint 1 -> Y -> SSL Endpoint 2 -> Z -> RECEIVER
when you look at X, you can see plain text
when you look at Y, you can see encrypted messages
when you look at Z, you can see plain text again
Related
Is there any added value in encrypted data we send in http request and response between client and server if we already have SSL / TLS ?
I get SSL/TLS already encrypts traffic across the transport layer for SSL/TLS connections but if we wanted to prevent browser users from reading request and response data, would encrypting it before it is sent add any value in preventing users being able to read it?
For instance, I could go to Network -> XHR requests -> and see what data is being transferred between client and server.
... but if we wanted to prevent browser users from reading request and response data, ...
It looks like you are trying to prevent the simple reverse engineering possible with using the developer console and looking at the requests and responses. While encrypting/decrypting the data in Javascript would make this simple reverse engineering harder it will not prevent reverse engineering in general: ultimately the browser needs to have access to the information in plain so some reverse engineer could tap into the relevant parts of your Javascript based crypto to get access to the data before encryption and after decryption.
In general: if the security of your applications requires protecting against the user of the application itself, then the security design is likely wrong.
I have read a lot of articles saying that in WCF you have two types of security one is transport level and other is message level. Transport level security must be used when you have intranet connection as it provides point to point security and underlying protocol should be SSL....
But if I search on how to secure public websites they all say use HTTPS(SSL) again SSL.
These two statements are contradictory.
Questions:
What exactly is the meaning of point to point security here?
If SSL is only point to point(and not end to end) then why people use it for public websites?
HTTPS encrypts data from point-to-point, and once the data reaches one of the points and is decrypted, no security guarantee is made from that point onwards. Intermediary nodes, however, cannot read the information.
Message security, on the other hand, can encrypt data to be decrypted only by a certain recipient, which can be a separate entity from the receiving end. The receiving end might eventually forward the encrypted message to the intended recipient who will be able to decrypt the message.
An analogy would be email. If you establish a connection with your mail server using transport security (e.g. HTTPS), any information is guaranteed to be secured from your machine to the mail server. However, anyone with access to the mail server (e.g. server administrators) will be able to read the content of the email.
On the other hand, if you use message security to encrypt the message so only a specified recipient can decrypt it, the actual email message is encrypted (and not simply the communication between you and the server), so that even once the message is received by the server, it is still encrypted. Only when the email server forwards your message to your intended recipient, the recipient can decrypt the message using his own private key, thereby keeping the email private across a whole path of delivery while not requiring direct communication by the sender and that recipient, as is required by transport-level security.
Of course, some parts of the message must remain visible to the email server, for example the recipients address, and so you may want to use both levels of security: message security will ensure the mail server (or any party except the recipient) can't read the content of your email, and transport security will additionally ensure that a third party listening in to the communications between you and your mail server can't find out who you're sending an email to (unless the mail server divulges that information to that third party
Taken from WCF Transport security weakness
Read more here https://msdn.microsoft.com/en-us/library/hh273109(v=vs.100).aspx
Answer to question 2 :
Because once it reached to the IIS Server which is hosted by the company itself/or in Data center which has all firewalls and other security measures which is hard to bypass which means no one can read your message from that server unless is can hack everywhere it saves oecerhead of tcp security.
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 want the ability to prove to a third party (not myself) that I received some given content from a given https server, or in other words, have a signature of that content that can be verified against the public key of the SSL certificate of a website.
According to this, it seems that a signature of the digest of the data is being sent and I am hoping that this is happening every time a page is loaded. If that is right, how/where can I see/extract that signature? (e.g. using curl, whatever command line, tool...)
If my last assumption is inaccurate, is there a way that I can produce the proof described above? And if so, how?
Thanks,
TLS uses data integrity control mechanism, but as the name suggests (TLS = Transport Layer Security), TLS is about protecting the data channel, not about "signing the data". TLS guarantees (or attempts to) that what has been sent via the protected channel remains unchanged in transit and it has not been altered by the third party. So you don't need to manually check any signatures besides the validation procedure performed by the TLS client on your behalf. If you trust your TLS client, then you trust the connection. You can perform additional checks of the certificate sent by the server, but you can't check the "signature of the digest of the data".
It's possible to craft a server which will calculate the signature of the data and put the signature to the response headers, but out of the box I didn't see any server doing this (or any client verifying such signatures).
On 2nd edition of "Programming WCF Services" By Lowy, ch 10, page 512.
Lowy said about Transport security: Its main downside is that it can only guarantee transfer security point-point, meaning when the client connects directly to the service. Having multiple intermediaries between the client and the service renders Transport security questionable, as those intermediaries may not be secure. Consequently, Transport security is typically used only by intranet applications.
HTTPS is one of Transport security options, How previous paragraph applies to HTTPS ?!!, HTTPS encrypts every thing all the way from start to end points. Also every e-commerce application in the world is using HTTPS, how you can limit it to intranet applications!!
Thanks
HTTPS encrypts data from point-to-point, and once the data reaches one of the points and is decrypted, no security guarantee is made from that point onwards. Intermediary nodes, however, cannot read the information.
Message security, on the other hand, can encrypt data to be decrypted only by a certain recipient, which can be a separate entity from the receiving end. The receiving end might eventually forward the encrypted message to the intended recipient who will be able to decrypt the message.
An analogy would be email. If you establish a connection with your mail server using transport security (e.g. HTTPS), any information is guaranteed to be secured from your machine to the mail server. However, anyone with access to the mail server (e.g. server administrators) will be able to read the content of the email.
On the other hand, if you use message security to encrypt the message so only a specified recipient can decrypt it, the actual email message is encrypted (and not simply the communication between you and the server), so that even once the message is received by the server, it is still encrypted. Only when the email server forwards your message to your intended recipient, the recipient can decrypt the message using his own private key, thereby keeping the email private across a whole path of delivery while not requiring direct communication by the sender and that recipient, as is required by transport-level security.
Of course, some parts of the message must remain visible to the email server, for example the recipients address, and so you may want to use both levels of security: message security will ensure the mail server (or any party except the recipient) can't read the content of your email, and transport security will additionally ensure that a third party listening in to the communications between you and your mail server can't find out who you're sending an email to (unless the mail server divulges that information to that third party).