5

They say:

GitHub Pages sites shouldn't be used for sensitive transactions like sending passwords or credit card numbers.

This, even though they officially support HTTPS.

See this scenario: I'm hosting static website on Github, with HTTPS enabled. I have a server running in a cloud, and all the non-static information I gather/display on the static website is stored on/fetched from this server, over HTTPS.

If the static website is behind HTTPS, and all my connections to cloud servers are HTTPS too, then I should be able to use Github Pages for sensitive transactions like sending passwords or credit card numbers, right?

I am curious what's the reason Github says you 'shouldn't do it', although I feel there is a way to be secure while using GitHub pages.

Rushi Agrawal
  • 181
  • 1
  • 1
  • 6
  • This is, because HTTPS is not confidential, just secure, there is no authorization. – GiantTree Sep 24 '16 at 19:08
  • 1
    If you handle credit card numbers then you need to adhere to PCI-DSS, something that Github will almost certainly not have and will have no intention of getting. – Richard Sep 24 '16 at 19:15

2 Answers2

2

HTTPS encrypts/protects information in transit (ie from client->server and server->client), but not information at rest. So, even if you put passwords or credit card information on your page and somehow get it behind and authorization wall, the data is not implicitly encrypted by GitHub in such a way as to prevent hackers who might hack into GitHub from simply exporting that data from their system.

Essentially it's a liability thing. :)

David Woodward
  • 1,242
  • 8
  • 21
  • Edited the question to include more information. Thanks! – Rushi Agrawal Sep 26 '16 at 13:55
  • 1
    I'm sure there are cases where it can be secure enough to act as a front end for other more robust server solutions like you describe. But, they'll probably still say you're in violation of their terms for liability reasons. Examples of valid arguments would be: Does the GitHub page contain some kind of credentials, certificates, or keys used to authenticate with the secondary server? Does it essentially wrap pages from the secondary server in a frame on the GitHub page? In either of these cases a hacker could still use the GitHub page as a stepping stone to access sensitive data. – David Woodward Sep 26 '16 at 17:34
1

The reason is that github uses Let's Encrypt domain validated (DV) SSL certificates. These certificates require that you show ownership of the domain by either creating a DNS record on the domain you want an SSL certificate for or uploading a file to the website your domain points to. Just because you own a domain name doesn't mean you have authority to conduct business for a given company that appears on the domain's website.

You should use an orginzation validated (OV) or extended validation (EV) certificate if you want your users to be certain your website has authority to conduct business for the name used on your website.

In an OV certificate you will see the registered business name in the certificate's subject field. For example this is what I see when I go to wellsfargo.com so I know for certain who exactly owns wellsfargo.com, because a domain name by itself isn't authoritative when you can create any domain name you want that's not already taken.

CN = www.wellsfargo.com
OU = DCG-PSG
O = Wells Fargo & Company
L = San Francisco
S = California
C = US
SERIALNUMBER = 251212
1.3.6.1.4.1.311.60.2.1.2 = Delaware
1.3.6.1.4.1.311.60.2.1.3 = US
2.5.4.15 = Private Organization

Now that I have a name and address, if I want to keep going down the rabbit hole to verify this information, I can go to California's record search and see their articles of corporation if I want to know more about Wells Fargo & Company for example their offical address or how to officially contact them: https://businesssearch.sos.ca.gov/Document/RetrievePDF?Id=02160471-4750627

https://community.digicert.com/en/blogs.entry.html/2015/04/16/dv-ssl-certificates-and-ecommerce-dont-mix.html

Timothy Gonzalez
  • 111
  • 3