I am developing an online-shop based on a Telegram Bot, and I need to host it on a VPS. What are the dangers if I use a self-signed SSL certificate?
I found online that there's a MiTM attack threat, but I couldn't find a detailed explanation on how it can be avoided when using a self-signed SSL.
For example, will it help if all requests are sent to/from a URL of type: www.example.com/?
This is based on my reading of the Telegram Bot API.
There are two ways to control your bot, both of which involve "reasonably" secure protocols that are hard to man-in-the-middle (MITM). First, all communications with the Telegram server using the Bot API uses HTTPS. You must authenticate the Telegram server by doing a proper certificate chain validation. Telegram both authenticates you and identifies you by checking the token you supply in your HTTP request. This token was given to you when you created your bot and must remain a secret.
In addition, you may also elect to receive updates via a webhook. This basically involves you running an HTTPS server using a self-signed certificate. However, you provide your certificate to Telegram over a secure mutually authenticated connection when you setup the webhook, so this eliminates the MITM threat. The Telegram documentation suggests a method you can use to verify that the connection is coming from Telegram.
CAVEATS:
I've never implemented a Telegram Bot, so this is just based on reading the Docs.
Simply because it looks secure to me after 10 minutes of study doesn't make it so. Since this is a unique protocol within HTTPS I would want to see some expert analysis before I'd be confident.
Related
Is possible to use Auth0 server over HTTP intead of HTTPS?
If yes, how to?
If not, why?
(I known the http is sniffeable)
It's not possible.
A secure transport layer is required on all of the communication flows used in the authorization protocols supported by Auth0: OAuth2, OIDC, SAML and WS-Federation. This is to ensure the security of items such as credentials, tokens, and personally identifiable information.
HTTPS is also required on mandatory for the administration Dashboard and every related service. Again, it wouldn't make sense to exchange information used to secure systems over an insecure protocol.
I want to know if SSL certificate and URL starting with https:// is mandatory for webhook of a Telegram bot?
As it noticed in https://core.telegram.org/bots/api#setwebhook it seems it is necessary, but I'm not sure about this.
As Telegram Bot documentation says:
All queries to the Telegram Bot API must be served over HTTPS and need to be presented in this form.
You need a valid SSL certificate for webhooks to work.
To use a self-signed certificate, you need to upload your public key certificate - using the certificate parameter in setWebhook. Please
upload as InputFile, - sending a String will not work.
Ports currently supported for Webhooks: 443, 80, 88, 8443.
Wildcard certificates may not be supported.
Redirects are not supported.
CN must exactly match your domain.
Setting up SSL is not hard and there or completely free ways too(like free valid SSL certs or self-sign methods)
HTTPS is widely used for security online. It offers security and integrity, but not authentication. To ensure the client is not talking to a man-in-the-middle, we have digital certificates and the PKI. It all works very well, except in the situation where the following criteria apply:
The server and client do not share a common, trusted root CA, therefore they cannot validate each other's certificates
Circumstances (eg. firewall, permissions, etc) do not permit the use of regular HTTPS protocol
The question is: can we still send secure, authenticated messages between the client and server, perhaps using Javascript?
Something along the lines of:
Client sends regular HTTP request to server
Server responds with page containing Javascript code
Client's Javascript asynchronously sends data to the server used to negotiate
Server runs some sort of script (eg. PHP) to establish the tunnel
Client and server communicate over the encrypted tunnel
I can see it being possible to send messages with security and integrity in this manner, but is it possible to authenticate without making use of the PKI, perhaps by exploiting the fact that the server can dynamically rewrite the Javascript sent to the client?
There is an issue in your step 2 - Server responds with page containing Javascript code :
how do you know someone sitting on wire is not modifying this Javascript since it is being transferred in plaintext? Basically, when X wants to authenticate Y, X should know something about Y- it could be public information such as public key/certificate or shared secret that it could verify
There is something I don't understand, When I don't put certificate at all, the SSL connection is established successfully, I wonder how the server decrypt the message without client certificate.
What is client side certificate is for?
Thanks
As I understand it (the 15000 metre view.)
The server has a public key it publishes in its cert. This is used by your browser to encrypt everything it sends. Only the server can decrypt the info as only it (hopefully) has the private key.
If you have a client cert then you give this to the server to ensure that it encrypts stuff to you so only you can decrypt it (again with your private key).
So to me: You can send your credit card info completely freely, knowing that only the server can read it. The client can either then send a proper cert or create a 'temp' one for the session and then the 'public' encryption key to the server secure in the knowledge that no one else will have sent it. Then the comms are encrypted both ways, but separately.
Now from here
A TLS client and server negotiate a
stateful connection by using a
handshaking procedure. During this
handshake, the client and server agree
on various parameters used to
establish the connection's security.
The handshake begins when a client
connects to a TLS-enabled server
requesting a secure connection, and
presents a list of supported
CipherSuites (ciphers and hash
functions).
From this list, the server
picks the strongest cipher and hash
function that it also supports and
notifies the client of the decision.
The server sends back its
identification in the form of a
digital certificate. The certificate
usually contains the server name, the
trusted certificate authority (CA),
and the server's public encryption
key.
The client may contact the server
that issued the certificate (the
trusted CA as above) and confirm that
the certificate is authentic before
proceeding.
In order to generate the
session keys used for the secure
connection, the client encrypts a
random number (RN) with the server's
public key (PbK), and sends the result
to the server. Only the server should
be able to decrypt it (with its
private key (PvK)): this is the one
fact that makes the keys hidden from
third parties, since only the server
and the client have access to this
data. The client knows PbK and RN, and
the server knows PvK and (after
decryption of the client's message)
RN. A third party may only know RN if
PvK has been compromised. From the
random number, both parties generate
key material for encryption and
decryption.
This concludes the
handshake and begins the secured
connection, which is encrypted and
decrypted with the key material until
the connection closes.
This wikipedia article probably gives more info than you'll ever want.
Think about certificate not in terms of encrypting-decrypting, but in terms of authentication. Encryption can be done without certificates at all - just knowing open key is enough. But certificate contains different fields, among them is personality of certificate owner. For web this value is the domain name of the server you wish to connect to. As there are means to check that IP address of the server is always equal to name stated in certificate (forward and backward DNS requests), you can be sure that you're talking to the one you wish to.
In this terms, client certificate issue should be much simpler to understand. Client certificate allows server to authenticate client, so the authentication will be mutual. Server could check, for example, that the client certificate is valid (not expired, not black-listed, etc.).
Using a certificate from either the server or the client will give the endpoints a means of exchanging a shared secret (a symmetric encryption key - or seed).
A secondary purpose for the certificate (and one that's much less well-leveraged these days, relative to "encrypting the channel between endpoints") is to authenticate the endpoint supplying their digital certificate (using the cert and the proof of possession that they also send).
The overwhelming majority of SSL transactions these days are effectively only worried about the "encryption of the channel", not to authenticate the endpoint. (Practically speaking, it's a side benefit on the commercial internet, though the mass of man-in-the-middle attacks out there give us increasing incentive to try to figure out how to really know you're talking to the server - or client - that you think you are.)
In other words, the client certificate would be useful to authenticate (in a more or less "stronger" manner) that the server is interacting with either (a) a "more trusted" client (if all you were doing was ensuring that the cert is among a pool of certs you trust - e.g. mapped to an LDAP/AD directory of users you deem "trusted", or issued from a CA whose issuing practices you "trust") or (b) a specific user that you authenticate (e.g. again, through an LDAP/AD database of user, one - or more uncommonly, or more - of which has been mapped to that certificate through some automated or out-of-band - but either way, hopefully a sufficiently secure - process).
What makes https more secure than http?
The short answer is that https communication between your browser and the server are encrypted. While http traffic is sent in plain text. This means that anyone who can listen to the traffic can read it - this would include usernames and passwords). It also verifies the server to which you are connecting.
That it is encrypted. Read: en.wikipedia.org/wiki/HTTP_Secure
Anything not over HTTPS can be read by anyone snooping on your network.
Im quoting:
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server.
More information on TLS:
The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. TLS provides RSA security with 1024 and 2048 bit strengths.
Also, HTTPS verifies that the site is who it claims to be, if the certificates are correct (signed by a known CA).
All traffic is encrypted. No one on your network can see what is going on (except for knowing where those packets are going to).
The identity of the remote server can be verified using certificates. So you also know that it really is your bank that you are talking to.
Optionally (and not in wide-spread use), the identity of the client can also be verified using certificates. This would allow for secure login to a site using chip cards instead of (or in addition to) passwords.
I want to be really pedantic, as I'm a security nerd :)
HTTPS uses SSL, and it's IETF-ratified cousin, TLS. SSL/TLS can offer four security services:
1) server authentication
2) channel encryption
3) channel tamper detection
4) client authentication
Usually you'll get server auth for free, but only if the host name and the common name in the server's SSL/TLS certificate match. If they don't match your browser will warn you. You usually get the channel defenses for free too, but that's only because the server and client negotiate to require such defenses. In theory, but rarely in practice, a server and client could agree to not use one or more of the channel defenses.
Finally, client authentication is when the server wants you to present a certificate (actually, to prove you have an associated private key) to verify you are you. Client authentication is rarely used.