I apologize, I know this is a very short question but Google doesn't seem to help (I guess I'm not searching for the correct phrase or set of keywords).
If I have a site not protected by SSL and it makes an api call to an https site, is that information secure or do I need to have SSL as well?
I want to make sure I keep my users' data secure.
Only data in the API call (request) needs to be protected. Data returned by the API (response) to my (non-SSL) site isn't meaningful or sensitive.
Thanks in advance.
The call to the SSL site will be protected, but if it's multihop (client to non SSL to SSL site) and the data on first hop is plain text.
However as #VictorRonin says, security is a much bigger concern than just SSL.
The call is protected. Your website talking to another website (protected by SLL) will send and get information inside of protected channel.
However, it's hard to say whether your users data is secure. Security requires a lot more than just usage of SSL.
I also got the same problems.
I'm using 16 bits micro connect to net by Wifi's AT command .
after connected in transparent mode. normally I can send some simple text (HTTP ) to request content from every web page.(if those webpages not need SSL).
this makes programing fun and easy.
But these few years. life got stuck almost webpage use SSL. mean programming need more complex step to reach content.
but the most serious things is that the CA (cert auth) cannot use forever it has expired time !!!
This mean hardware device have to modified CA data frequently . so it's not practical for small iot firm .
However I found a way even it's not the best by using thingspeak.com (ThingHTTP)
with ThingHTTP you can request without SSL to any website which need SSL
I hope in the future there are more iot cloud or even some webpage turn to use old method (HTTP) in case of that data no need secure.
In my opinion user can encode/decode the data by themself instead of secure everything in webpage.
Thnks
Related
SSL is very important to protecting users private data on your website.
The more I see SSL used on websites; I have noticed that it is not used all the time like Facebook, Ebay, Google (Youtube) etc...
So my question is: Why pay for a SSL and have the ability to encrypt data while it travels over insecure networks (Internet mainly) then not use it on the whole site?.
Why only encrypt parts of sites?
Why not just force SSL on page load?
It does occur to me that it must be a good reason as it does not slow done the page by having one.
I was thinking of getting a SSL for my website so people can contact me without other people being able to see what they are sending (in case sensitive information really). So should I encrypt the whole site or just that one page.
Thankyou for any help / thoughts on this matter.
Have a good day :)
Why pay for a SSL and have the ability to encrypt data while it
travels over insecure networks (Internet mainly) then not use it on
the whole site?
In theory a webpage over SSL is slower, so some people avoided putting the whole site under SSL.
Should I encrypt the whole site or just that one page.
The whole site would be easier, and I doubt your site would have any problems with performance based on SSL.
I really appreciate your thinking to make your whole website run over encrypted channel with SSL security. Many websites avoid to use ssl on all webpages, but in my personal opinion; if your website contains account log-in and sign-up on every page then it should be protected.
Whether you are running website over HTTP or HTTPS, it rarely affects website loading time & affect your website performances. In current time attacker always try to attack on website anyhow. Secure transmission of data reduces the risk of hacking and allows user to trust upon your website.
im using silverlight 5 and WCF .. and the site is secured with HTTPS . however if i use fiddler , i can see this in the headers:
GET /ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
if i put that directly after my domain : https://www.mydom.com/ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
it will download all data from tabel users. how can i hide and protect this information from being visible!! isn't using SSL enought ? why is this visible anyways if im using https!?
thank you.
EDIT: my initial question was kind of an 'uneducated' one and for that i apologies,
i found more info on the subject and did more research. in this Q on SO there is an explanation to why fiddler is able to decrypt and view requests and responses sent over https.
What is point of SSL if fiddler 2 can decrypt all calls over HTTPS?
and to make things even more difficult, the common solution to this problem is using
"Certificate Pinning"
which requires the use of System.Net.ServicePointManager which is not included in the silverlight implementation of System.Net namespace.
so here i am stuck with an SSL cert. that i paid for that can be "cracked" by anyone with basic knowledge of web debugging.
From a purely Theoretical Computer Science point of view, what you are asking for is near impossible to actually impossible. You would need to implement a trusted platform to protect against the attack.
Now for the Science bit, Concentrate
Okay, so lets start with some basic theory. SSL and thus by extension HTTPS solves a very very specific problem. How do you communicate information over an unsecure NETWORK confidential information with a party you have never communicated with before. In this case, the emphasis is on NETWORK. It does so by solving two problems,
Authentication of the server (the server is who it says it is)
Asymmetric Encryption of key exchange
There is some overlap, to ensure that this is one step. I will focus on the 1st, as this is where fiddler "attacks" your system.
The SSL authentication works on a concept of a web of trust. Your computer has a list of TRUSTED verifiers. These are companies like Verisign, Thawte, Geotrust etc. These companies verify certificates by signing them (complex asymmetric encryption term, but its very like a handwritten signature, hard to forge, easy to verify).
Fiddler works by inserting a new trusted CA (verifier) into your computer. From then on, when you visit an HTTPS site, it will send requests on your behalf, reads it then forwards it back on to you with its OWN SIGNATURE. Since your computer completely trusts this signature, it thinks nothing is wrong.
Now, you want to implement certificate pinning. This IMHO is "bloody awful". It works by telling your software to expect a specific SSL cert. Two reasons why this is bad.
If I can work Fiddler, I can work dotPeek and recompile WITHOUT certificate pinning.
When your certificate gets revoked, your clients won't be able to connect.
Why would your certificate be revoked? If your CA loses their private keys, then they will be obliged to make sure its revoked and a replacement sent to you. Also each and every certificate has a sell by date as well, and must be replaced before they start to smell.
So finally what can you do?
SSL is NOT designed for protecting against what you are doing on your machine. The simpliest way to do what you are asking is to simply wrap your WCF calls in an extra layer of symmetric (or even asymmetric) encryption. But once again. The keys must live somewhere, so your client WILL be able to get the keys from a simple disassemble of your binaries and be able to construct a proxy of their own.
In conclusion
This is pretty much exactly the same as the DRM problem. You want to give your customer access to something on their machine but not show them how it works. If you do manage to solve this problem, do post a follow up, since Sony, Nintendo and Microsoft (to name a few) would be very interested in your findings.
I'm in the process of designing a REST Api and we're trying to decided how to do encryption. We are currently using https for all request/responses however various logs (dns, browser, ...) will log the plain text url. This raises an issue when we're sending sensitive data in the url, such as "www.mysite.com/user/credit-card-number/". Is there a way to leverage the SSL/TLS public/private keys to encrypt path parameters? For example, "www.mysite.com/user/credit-card-number/" turns into "www.mysite.com/encryptedstring".
I would highly recommend that you not put sensitive data in the URL. If you need something identifying, you could at least use a randomly generated String/UUID/token/whatever that maps to whatever it is that is being identified.
Handling manual encryption/decryption would depend on what language/framework you are using. For example, if you were using Java, then do some google searches on JSSE, which is Java's framework for SSL/TLS.
If you're looking for something to automajically do the encryption/decryption for you, I would think that would also depend on the framework you are using.
If I understand correctly, you are asking if urls are encrypted over an SSL/TLS channel. The answer is yes as this SO question points out. Over TLS, everything is encrypted between the client and server except the IP address and port of the targeted server. (This includes the http headers as well.)
EDIT:
After reading again, I see that you are interested in stopping the the URL being logged. I'm pretty sure the only way to do this is to change the url on the server. Not much help, but my suggestion is don't put the cc number in the url or use some kind of derived key instead.
I'm running a dating site and not using SSL at the moment.
I've noticed major sites like facebook and twitter do not use https for login but just use plain old http, is there really any advantage to https-ing my site or it is only for cc transactions or so ?
thanks in advance.
Actually, facebook does use https for its login:
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">
as does twitter:
<form method="post" id="signin" action="https://twitter.com/sessions">
You'll notice they don't use https for the page that displays the signin form. That's because it isn't necessary.
However, it's a good idea to use ssl the login itself if you can, if only because so many users employ the same password for all sites.
One solution, which I'd like to see more sites employ, is using OpenID/OAuth for login instead of requiring a username/password.
SSL encrypts the traffic between the browser and the server. So virtaully anything you want to be secure needs to be ssl'ed. Google search is even doing it so poeople can't have their search terms intercepted.
Its just the case of what YOU want secure, and if not having certain parts of your site secure will keep wanted customers away. I would think a dating site has a lot of personal demographics information that some people might want secure... just my 2 cents.
SSL is used only when transmitting sensitive data between browser and server. It's fine for major sites like facebook and twitter to use http (as long as the data is not sensitive). Most website use SSL for their login page. SSL also used by payment gateway to safely transfer payment information through the wire.
And by the way, http is not "plain old" and https is not new trend either :)
If your users are providing any sensitive data, ssl prevents it from being intercepted by a third party. If you don't use SSL, you should assume that some third party can see everything that every one of your users does on your website. If you are comfortable with them seeing this information, then keep it plain http, but if you don't like that thought, go https.
Another benefit of ssl is that it allows the use of Strict Transport Security, which not only forces https on all site activity, but also prevents a man in the middle from spoofing your site to a user and making them think they are accessing your site. Details here: http://en.wikipedia.org/wiki/Strict_Transport_Security
I work at a major ISP and am infatuated with one of your online members. By sniffing your packets, I can find out when and where she's meeting another member, rewrite the packet to change the location so the other guy doesn't show up, and then make my move.
You decide whether that's acceptable to your users.
Https is useful to protect the credential (user/password) , but it increases the network load and requires more CPU resource (encryption). Thus, it is common to use only for authentication.
Https ,with server certificate protects again phising.
Banks uses end to end application
I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.