4 ms·

EDIT: to avoid any FUD, there's no problem with the URL; as the replies say, the path of the target URL is encrypted under SSL. --- ORIGINAL: I have a questio

• naz 14y ago
  HTTPS URLs are encrypted along with the rest of the request.
  • callmevlad 14y ago
    If a web designer adds this script to a non-HTTPS page, is that still the case?
    • boucher 14y ago
      Yes, the request is still encrypted. However, the original page will be subject to man in the middle attacks, which is why Stripe requires that payment pages using the Stripe Button or Stripe.js are served with SSL.
• jonknee 14y ago
  That is interesting, the form is a POST, must be Javascript doing the GET in its place. I wonder what the technical advantage of GET is in this case.
  • jtolj 14y ago
    Maybe has something to do with this: https://stripe.com/blog/stripejs-and-jsonp https://stripe.com/blog/stripejs-and-jsonp (they mention JSONP only supporting GET requests)?
    • jonknee 14y ago
      Yup. Duh.
  • exogen 14y ago
    The technical advantage is getting around the same-origin policy by using JSONP (which by its nature can only be used with GET requests for the script).
  • deleted 14y ago
    [deleted]
• Cushman 14y ago
  The path part of the URL is encrypted along with the rest of the request. Only the DNS lookup (i.e., the hostname) is in the clear.
  • pfraze 14y ago
    Okay, thanks for clearing that up for me.
    • Cushman 14y ago
      Not at all, sorry for piling on :) I swear there were no other replies when I commented.
  • mjschultz 14y ago
    Wouldn't stripe's server logs also have the get params in cleartext?
    • cmaggard 14y ago
      They're most likely being scrubbed out, same as you would with passwords.
• aneth4 14y ago
  The path and parameters of the URL are part of the HTTP conversation that is encrypted. In a simple sense, only the host name and IP address are not protected.
  • lftl 14y ago
    Isn't the hostname encrypted as well? My understanding was that's the reason you have to have a unique IP for SSL and can't rely on a vhost setup.
• jaemccall 14y ago
  SSL encrypts the query string. The only thing in the clear on the wire is the domain name (api.stripe.com). Although there may be other ways for GET query data to leak out (bookmarks, plugins...)
  • tlrobinson 14y ago
    Even the domain name (in the Host header) will be encrypted (unless SNI is used? http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication)
    • mooism2 14y ago
      The domain name is unencrypted in the dns lookup.
      • jsilence 14y ago
        This is OT, but actually I wondered why there is no dnss equivalent to https. Leaking the domains you visit through dns queries is also a problem for TOR and other anonymity systems. Usually the DNS resolver one uses is provided by the ISP. Of course you can change that, but then still the unencrypted DNS queries are sent through central points on the ISP side, making it very easy for them to connect your account with the domains you visit.
        • masklinn 14y ago
          > actually I wondered why there is no dnss equivalent to https. There is one by djb: http://dnscurve.org/ http://dnscurve.org/ OpenDNS implemented it in 2010 (they call their implementation DNSCrypt, it usually requires an OS extension)
          • jedisct1 14y ago
            The German Privacy Foundation has been offering DNS-over-SSL and DNS-over-HTTPS for quite a long time. OpenBSD accepts a "tcp" option in the /etc/resolv.conf file in order to force connections to use TCP so that they can easily be tunneled over SSH. The popular Unbound caching resolver can communicate over SSL to an upstream resolver, and there is even a nice GUI: dnssec-trigger. NLNet provides a public resolver that of course supports this protocol. dnscurve is a protocol for authenticating and encrypting data between an authoritative server and a resolver. dnscrypt is a different protocol (although partly based on the same crypto primitives as dnscurve) for authenticating and encrypting data between a resolver and a client. OpenDNS implemented dnscurve in 2010, and dnscrypt in 2011. All these protocols have issues in the real world, due to routers and firewalls intercepting DNS traffic, and dropping encrypted queries. Some broken devices and resolvers are even breaking DNSSEC (stripping records), but this is far less common. A workaround is to use a different port and protocol, typically TCP port 443. Or to use encapsulation in TXT records, which has different issues. dnscrypt's successor, called dnssig, is also being worked on in order to always offer authentication, and optional encryption.
• boucher 14y ago
  Cookies are only sent for the domain involved in the request, so only stripe.com cookies would be sent to Stripe, not any cookies for the domain hosting this button.
• untog 14y ago
  Still seems like a bad idea to use GET, though- those URLs often appear in logs. POST bodies do not.
  • toomuchtodo 14y ago
    DevOps here. You scrub those out.
    • k3n 14y ago
      PCI compliance largely requires that this such data never exist in the first place. Perhaps you can get by with scrubbing after-the-fact if the disk is encrypted, but logs are still "data at rest" and on an unencrypted filesystem I don't see how you could be compliant.
      • tesseract 14y ago
        Most webservers that I am familiar with have configurable log formatting, so you could prevent it from being logged in the first place.
        • k3n 14y ago
          Yes, but the guy I replied to said he scrubbed it, which implies that they did not prevent anything from being logged, but instead they cleaned it up afterwards. Thus the reason for me saying what I did.
          • toomuchtodo 14y ago
            The logs sit on a ramdisk before being scrubbed; power removed before scrubbing? Logs are lost, but PCI compliance is maintained.