![]() Openssl req -x509 -new -nodes -key ca.key -sha256 -days 1024 -out ca.pem -subj " $CA_SUBJECT" # create a. Openssl genrsa -out ca.key " $KEY_SIZE" # self-sign the certificate authorityĬA_SUBJECT= " $SUBJECT/CN=Mixmax Engineering" # add a common name ![]() SUBJECT= "/C=US/ST=California/L=San Francisco/O=Mixmax/OU=Engineering"ĭOMAINS= " " # generate the certificate authority private key Finally, we'll add the certificate as trusted to the root certificate store, which instructs Chrome to trust the certificate. We'll also create a self-signed certificate authority with which to sign the certificates. To support arbitrary servers and minimize the number of changes we'll need to make if we add a new subdomain, we'll use wildcard certificates for *. and *. In our case, we have a number of different domains we'd like to handle, including those on two separate second-level domains: and. Since we don't want to use real certificates, we'll need to generate our own. Were any developer's computer compromised, the attacker could use the certificates to intercept legitimate traffic to the real servers, and cause real damage to both users and the company. Generating the CertificatesĪny https connection requires a set of certificates, which serve to prove the identity of the organization or entity on the other end of the connection, and to encrypt the data between the two parties.Īctual certificates should not be used during this process - they are not necessary, and distributing them opens them up to unnecessary risk. The straightforward solution entails enabling our local proxy server to serve content over https so that the content security policy allows our app to function. We'll also discuss the changes we made to support our existing livereload mechanism. We'd like to share our findings while reducing friction in our development workflow, specifically regarding changes to our proxy server. This introduces developer friction, and makes results from testing locally inconsistent with results post-deploy, so we'd like to mitigate this problem. When a web page exhibits this behavior, it is called a mixed content page.Īs a result, we've had to run Chrome in an insecure mode when testing our changes. If the HTTPS page includes content retrieved through regular, cleartext HTTP, then the connection is only partially encrypted the unencrypted content is accessible to sniffers and can be modified by man-in-the-middle attackers, so the connection is not safeguarded. When a user visits a page served over HTTPS, their connection with the web server is encrypted with TLS and is therefore safeguarded from sniffers and man-in-the-middle attacks. Gmail's content security policy makes it so that if you inject content that uses insecure resources, the requests for those resources are rejected. Read more about content security policy on HTML5 ROCKS. When those resource requests are rejected, our app fails to load, which makes it impossible to test during development. A strict content security policy like Gmail's is intended to keep the user safe, in particular disallowing insecure requests on a secure page. ProblemĪ content security policy determines how the browser handles requests to origins different from the page's origin. Up until this point, unlike our production environment, our proxy only handled http connections. This parity means we don't need to hard-code a microservice's port to make a request to it. To maintain consistency and functional parity with our production environment, we put a proxy server in front of our microservices, which handles requests to specific domains, such as, and forwards them to the appropriate server. ![]() For development, however, we need to host our microservices locally. Every service sits on its own fully-qualified domain name (FQDN) -, , and, respective to the aforementioned services. We have a microservice for serving contact autocomplete, rendering out the compose modal, displaying the dashboard, and more. Our platform is hosted across a set of microservices, each having a unique role. This creates issues during our normal development workflow, where we configure the app to refer to local resources. As such, we need to load all our resources over https - both for the security of our users, and to comply with Gmail's strict security policies. Mixmax is a rich communications client integrated directly into Gmail using iframes. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |