I want to be able to expose my local machine address to the internet to be able to work with:
Google OAuth2 flow;
Receiving Push-Notifications for changes in my calendars/events;
So that, I need some tool that will expose my local machine URLs to the Internet so Google will be able to use this web hooks.
I found that ngrok with basic(5$) subscription works for me. Free versions doesn't work since I need SSL as it's required by google:
This is your Webhook callback URL, and it must use HTTPS. Note that
the Google Calendar API will be able to send notifications to this
HTTPS address only if there is a valid SSL certificate installed on
your web server. Invalid certificates include: • Self-signed
certificates. • Certificates signed by an untrusted source.
• Certificates that have been revoked. • Certificates that have a
subject that doesn't match the target hostname.
The question is whether there is something else I haven't taken into account that will force me to buy more expensive type of subscription? Maybe some specific requirenments from Google that basic subscription can't work with.
Basic $5 subscription works perfectly. It fits all Google's requirements + it provides static URLs that make it possible to receive PUSH notifications even when you restart your ngrok or computer.
Related
I'm using google firebase Messaging for push notifications of my website.
my website doesn't have a domain. Its using HTTPS with self-signed certificate.
as i realized service worker needs HTTPS with valid SSL certificate. witch isn't available for sites without domain.
in some of other push notification services there is an option for HTTP websites that it opens a new window with a sub domain and notifications will be received from there.
is there any free option in any site that provides such future?
or
is there another option for me to pass invalid SSL error when enabling service worker?
btw: i'm aware about browsers flags for allowing self-signed certificate. i'm not gonna use that because i have some users now.
my frontend is a angular cli app running with nginx on a ubuntu server.
I have a Flask API which has no database but just a json file that stores the data. At the moment I have put it on an EC2 and opened a port so someone can put in the IP address and port and have access to the API that way. The problem with this is that I get a mixed content error since the site it uses is HTTPS and the API is HTTP. I want to put the API behind HTTPS on a proper platform but I'm not sure where to start.
Is there a platform that I can host the API python file and the json file behind an HTTPS?
All of them? EC2 allows HTTPS (per #tawfikboujeh's comment). I don't actually know a hosting platform that would allow HTTP but not HTTPS.
There are some options in how you accomplish this:
Use a self-signed certificate. This will give you HTTPS but all the modern browsers will give a nasty warning to all your visitors.
Purchase a signed certification for you IP address from a CA. Just hope you don't have to change your IP address.
Purchase a domain and use Let's Encrypt to generate a signed certificate for you.
Option 3 would be the most robust solution, but it does carry the cost of a domain (maybe $10/year).
Google App Engine is perfect for this. SSL cert is free, and you would be in their free tier.
https://cloud.google.com/free
I have a problem with insecure SSL certificates. My proyect consist on two parts:
ESP32 iot device with a https server
VUE2 + Vuetify PWA web app deployed to firebase hosting.
Imagine that one client buy my iot device, and connect it to the power. The device will boot in AP mode, creating a WiFi AP net.
The client login to the web app and wants to add his new device. So, for that, the iot device needs clients wifi credentials.
The web app asks to the client his ssid and password, and when the client click on 'Configure device', the web app send a https POST request to the esp32 server, and here is the problem...
Because the SSL certificate used in esp32 server is not validated by an authority, the web app can´t make the POST request...
How can I get a valid server SSL certificate for a lot of iot devices? I don´t know how to manage this situation...
Thanks everyone!!
It is possible to get a valid SSL certificate for the device, but I wouldn't recommend it. Here is how you could do it if you wanted to:
Ensure that when your device is in AP mode, it's always available at the exact same IP address. For example, ensure that the ESP32 is listening at 192.168.1.1.
Register a domain like example.com. Add an A record to your DNS server for iot.example.com, with the value 192.168.1.1.
Obtain a valid SSL certificate for iot.example.com from any trusted authority. Put that certificate and associated key on your device.
Now, when your user connects to your soft AP, they can browse to https://iot.example.com and actually see a valid certificate.
However, I would really recommend not doing this. You'll have three major issues to contend with:
The key for your SSL certificate will be on your device's flash. If anyone extracts it, they can masquerade as iot.example.com. You can mitigate this by using flash encryption, but it's still not great.
The maximum validity period for an SSL certificate is around two years. So your provisioning flow will break after a couple years.
If the CA that issued your certificate hears that the private key is floating around and could potentially be compromised, they will probably revoke your certificate.
Instead, what you should do is secure your soft AP with WPA2, and a password that you can give to users. This will ensure that the connection is encrypted, and you can serve your provisioning form over HTTP instead of HTTPS.
An even better approach rather than trying to implement this yourself, is to use the ESP-IDF unified provisioning API. It takes care of the implementation details, and supports both Wi-Fi and Bluetooth as transports.
Regardless of what you decide to do, I'd highly recommend reading the ESP-IDF documentation on unified provisioning and the documentation on Wi-Fi provisioning, since they'll give you an idea of what's going on under the hood and what all is required for a secure implementation. In particular, you'll see that the Wi-Fi provisioning library does actually use a static WPA2 password like I suggested above.
I am looking for device authentication where
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
Each device will have a unique certificate that cannot be transferred to other devices.
A device certificate can be revoked anytime.
To achieve the above, I am planning to have another Service which would issue certificate to devices which is approved to use my service. I will issue the certificate via email to the user where he will install it manually. My users will use browser to access my service.
But I am not sure how would I achieve points 2 and 3.
Can you please guide as to how to achieve this using a self signed certificate?
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
You can use a SSL channel with client authentication or adding a digital signature to your messages
Each device will have a unique certificate that cannot be transferred to other devices.
it is not possible to ensure this using software certificates. If you distribute them by email, the user could install them in several devices.
You could use a hardware token (nfc/bluetooth) or preinstall the certificate in the Android/iOS KeyChain so it would not be extractable. but this complicates the distribution very much.
A device certificate can be revoked anytime.
Check revocation at server side before accepting a request from a client. There are standard protocols to do this ( OCSP, CRL), or use a custom mechanism since you issue them yourself
About a week ago I got the email below from Twilio letting me know about security updates and the possibility of compatibility issues on applications using older SSL client libraries. My app is hosted on Heroku, is not using a custom domain and piggy-backs on their SSL. This issue isn't an issue for me, is it? Heroku is usually on top of security and up to date on these things but googling I only find info on setting up SSL for custom domains on Heroku. Anyone have any ideas?
Twilio View Online Reminder: Security Certificate Changes
This is a reminder that on December 1, 2015 at 4:30 PM PT, we’ll be
updating api.twilio.com with a SHA2-signed certificate, a significant
improvement in encryption technology. From the official announcement
on October 8, 2015: Though the vast majority of applications will not
be impacted in any way, there is a possibility that applications using
older SSL client libraries may run into compatibility issues. To
verify that your application is compatible with the new certificate,
we’ve provided a test API endpoint at api.twilio.com:8443. Please note
this endpoint uses a different port from the current default port of
443. Make sure you specify that port in your Twilio SDK.
The validation endpoint will be deprecated on December 1, 2015 when
the new SHA2-signed certificate is deployed to the main Twilio API
endpoint (port 443). Please let us know at help#twilio.com if you have
any questions. We’re always listening and we’re here to help.
Cheers, Team Twilio
Twilio developer evangelist here.
This warning is not about your domain, but the SSL library on the platform on which you make API requests to Twilio.
Since you posted this question not long before the cut off came and it is now gone, I can't give you advice for testing this before the old certificates are removed. Basically, by now, if you are not seeing any errors in your application that makes calls to the Twilio API, then you are safe.
As you said, Heroku are normally on top of things like this and keep their SSL libraries up to date, so you should have nothing to worry about. I just spun up a dyno and ran some tests and everything seemed to work fine, so I suspect you have nothing to worry about.
If you were to have tested this before the change was made, you could have used the test endpoint on port 8443. In Ruby (I'm not sure what language you're using, but it's a good example anyway) you would do this:
require 'twilio-ruby'
account_sid = "AC123..." # your Twilio account sid
auth_token = "xyzabc..." # your Twilio auth token
client = Twilio::REST::Client.new(account_sid, auth_token, port: 8443)
Then, make any call to the API and check that it works over this port.
client.messages.list
If it does work then you are safe and have nothing to worry about.