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)
Related
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.
Recently I have been working on a website project that allows users to login with their Discord accounts to browse the website with their account.
The website utilizes the Flask-Discord library, Quart as my WSGI web framework, Hypercorn as my production server and Nginx as a proxy to pass web requests to my Hypercorn socket. I have set up an SSL certificate using Certbot-Nginx with Let Encrypt as the Certificate Issuer. However, after users are redirected to the Discord login page, the user logs into Discord and the callback is requested to my Quart Server I am receiving the following error:
oauthlib.oauth2.rfc6749.errors.InsecureTransportError: (insecure_transport) OAuth 2 MUST utilize https.
The website is set up and working correctly with a domain setup with noip temporarily and the SSL certificate valid, making all requests redirect to HTTPS instead of HTTP.
Is it possible that because the SSL certificate is set up with Nginx that the Python OAuth2 library is just unaware of the SSL certificate? It seems unlikely considering all requests are being redirected to HTTPS.
I've found plenty of people recommending to prevent such an error to just change the OAuth environment variables to allow for insecure transport but I don't want to compromise the security of the website.
Any ideas as to why this might be happening would be extremely helpful.
Thanks
This is happening because requests coming from Nginx reverse proxy is in HTTP form. Since you're running Quart app locally at say http://127..0.0.1:5000 and when Nginx makes requests to this URL, its starts with http. So insecure transport is done only from Nginx to your Quart app. You can supress this by setting "OAUTHLIB_INSECURE_TRANSPORT" = "true". More highlight on this: https://github.com/thec0sm0s/Flask-Discord/issues/3#issuecomment-676567390
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
I have a wordpress website using free hosting of Open Shift. When I search goole for my website name. I received a result that contain https ssl. But when I click this links google chrome will go to:
Attackers might be trying to steal your information from phamquan.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is phamquan.com; its security certificate is from *.rhcloud.com. This may be caused by a misconfiguration or an attacker intercepting your connection.
Because my website doesn't have ssl cerification. How can i disallow google index all links of my website as https. Only allow http links.
The only way to prevent Google from indexing the HTTPS version of the site is to stop listening to HTTPS. The main problem here is that your webserver is currently listening to HTTPS requests, although your website is not configured to deliver a valid certificate.
If you can't access the server configuration, another approach described here and here is to use the canonical link tag to link to the HTTP version of the site as a hint that the correct version is the HTTP and not the HTTPS.
Can I purchase a single SSL certificate for domain A and sign all of my other domains with the domain A as reference.
Will it work ?
You certainly can install those certificates. However just as with self-signed certificates the main problem is that they cannot be validated by browsers due to a broken verification chain.
In short: it won't work as you desire.
No, you can't. The certificate for SSL is issued with specific allowed usage (which is encoded in the certificate). This does not includes signing other certificates.
Consequently though you technically will be able to sign certificates for other domains using the key of certificate A, such signed certificates will not be validated right and will not work.
I think you're looking for wildcard certificates. Issuing a cert for *.mydomain.com would be valid for sub1.mydomain.com, sub2.mydomain.com, etc.
If you're looking to get a cert for mydomain.com and use that to generate a cert for otherdomain.com, that won't work.
FYI, wildcard certs are more considerably more expensive from what I remember.
EDIT:
Rereading your question, you want to do second option, and no, you can't do that. You'll wind up with an invalid cert and most browsers put up giant warning signs that the cert isn't from a trusted source. It will reference your cert for domain A as a trusted signer, which it is NOT, even though it WAS issued by a trusted signer further up the chain. If what you wanted to do was possible, the entire trusted signer/TLS infrastructure would be useless. (The utility of basic TLS as a verification that you're dealing with whom you think your dealing is debatable since it's trivial/inexpensive to get a cert. Hence the existence of Extended Validation Certificates.)
You can not sign further certificates from your certificate. Otherwise you could sign somethign like www.paypal.com under your own legitimate SSL certificate - This was demonstrated as possible via a MITM attack at a blackhat conference but this has since been rendered no possible.
However you can get Multi-Domain certificates. These certificates allow you to include additional domains in the SAN field (Subject Alternative Name). So the certificate is generated for a single domain and the additional domains are added during the enrollment process with your SSL provider. You will need to verify ownership of each domain you request.
These certificates allow you to host multiple FQDN on a single IP with one SSL certificate.
In addition there are also wildcard certificates but these only let you secure *.domain.com with a single certificate.