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?.
Related
Is it possible to have a cut down implementation of TLS , where we just
presume the server we are connecting to is trusted - after the server sends its
certificate, can we bypass verification of this and do away with any further
processing , and get right into standard http ? Is using public key encryption
something that is absolutely necessary , or can it be skipped ?
Rewording my question.
Is it possible to write a tls engine by skipping the need to use RSA public key
code ?,
or
Can a client notify the server during the handshake that it just requires the severs certificate
info, company name, expiry dates and requests the secret cipher key to be sent in plain text.
Skipping something in a protocol I don't fully understand is generally a bad idea.
Only steps marked as optional in the RFC can be safely skipped.
Therefore if you don't plan to use client-side certificate based authentication you can skip it.
However what you can do however is limit the number of variations in your implementation. This means support only one TLS version (e.g. TLS 1.2) and support only one dedicated cipher suite.
Anyway the pitfalls when implementing TLS are so numerous that I recommend you to use an existing implementation (e.g. implementing in a way that does not allow side channel attacks is not that simple and requires knowledge on that topic). There are other implementations beside OpenSSL with a much smaller footprint.
BTW: If you can presume the connection is trusted you don't need TLS. If you need TLS it should be a secure.
where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing
The point of verification is less to find out if the server is trusted, but more that you are actually talking to the server you expect to. If you omit this step you are open to man-in-the-middle attacks.
But, TLS is a very flexible protocol and there are actually ways to use anonymous authentication or a shared secret with TLS and thus skip usage of certificates. Of course in this case you would need to have some other way to validate the server, because otherwise you would be still open to man-in-the-middle-attacks. And because this use case is mostly not relevant for the common usage on the internet it is usually not implemented inside the browsers.
I am developing a secured Websocket server and realized that SSL at least requires server authentication.. That means, clients need to trust my certificates.
Is there a way to show up an "accept certificate" dialog at time the WSS is being established ?
What is the solution then ? Should I put the web application in an HTTPS connection ?
Of course I want to avoid having to manually send certificate to clients and asking them to trust it.
Thanks.
Websockets are not normal sockets. They are established by upgrading an existing HTTP(s) connection, so if you have HTTP they will be unencrypted and with HTTPS they will be encrypted and all the certificate check is already done before the upgrade to WebSockets started.
Well, the title says it all. For testing purposes I need that each SSL session will renegotiate its encryption parameters. Can I configure Fiddler in such a way to always decline a client's request to reuse previously negotiated encryption params, and force it to negotiate new ones?
Unfortunately, I don't know any way to force SChannel (the stack under System.Net.Security's HTTPS implementation) to do that.
One quick thing to remember is that when you have HTTPS decryption enabled there are two HTTPS connections in this scenario-- one from the client to Fiddler and one from Fiddler to the server.
If I'm connecting to a mail server over SSL or TLS but using PLAIN authentication, is that secure?
Since the SSL/TLS connection is already encrypted, sending the password as PLAIN text doesn't hurt anything. You could encrypt the password as well, but then you're just double encrypting it. In most cases, I would consider that superfluous.
One case I can think of where you would use something other than PLAIN over SSL/TLS is if you choose to authenticate with certificates instead of passwords. Otherwise, I'd leave it at PLAIN.
Ryan is absolutely right if you are sure if you will never use your application without SSL. SSL is at the presentation layer and whenever a socket connection is established, SSL handshake is the first thing that happens which includes host verification, exchange of session keys and creating a secure transport layer. Communication at the application layer happens once this secure channel is established and the data that is exchanged is encrypted using the session keys and hence the communication is anyways secure.
However, if your application has an option to work with/without SSL then you should be encrypting your password separately. While working over SSL, this would be redundant but otherwise it is necessary.
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.