On my site I'm using normal links HTTP , however where it contains data transaction, such as in forms, for example HTTPS use of a shared SSL certificate provided by my server hosting.
I do not want to keep it this way, I'll soon have bought a certificado SSL , but for now the site is mixed with HTTP and HTTPS on only a few pages.
Is it wrong to mix the two on a website in this way?
Overall, it's no problem. Of course you have to do it right. I realize that some people are not sure which pages should be encrypted, and end up encrypting what has no secret and sending decrypted data. That's the problem.
There is also some difficulty if a secure page loads unsafe elements, but it does not seem to be the case, this includes iframes so be careful if the insecure page is within a iframe contained on a secure page. >
Of course you may have a specific problem in some scenario depending on what you're doing, but it's more of a scenario, not normal.
As your plan is to encrypt everything afterwards there is no problem getting started like this. Future versions of browsers may start indicate problems, but they do not occur now. Even this will not make navigation difficult, there will only be an indication that it is on an insecure page. For everything there is a solution. It will only be a problem the day they force everything to be encrypted, which I doubt will happen. Still the problem will not be to mix secure and insecure pages.
Yes it is not recommended, and by the end of the year the chrome will not allow the site to be accessed without the user taking the risks and clicking accept insecurity as seen in this link , for this a free certificate was developed called Let's Encrypt , and today almost all the hosting uses and with free installation, it is also possible to install on LINUX servers autonomously if you are using any virtualized server from any platform.
If you use any hosting check that it does not already have the certificate. More about the certificate see here
If you use SSL, but do not use HSTS (and no HPKP) you allow an attacker to downgrade to HTTP.
Having SSL, without HSTS, is the same as nothing. You can not connect to HSTS (and neither HKPK), this will break access to the pages in HTTP.
The absence of these features allows HTTPS pages to go to HTTP. The attacker can do this and completely ignore SSL.
If you are loading script or img into HTTP and without using SRI and without CSP, you allow the attacker to modify the content. But, this is irrelevant because it can already modify the entire page. Whereas the attacker does some DNS Poisoning or ARP Poisoning, for example.
If you have a secure subdomain, such as seguro.site.com , you have to insure that it uses HSTS, at a minimum.
This still has other problems. For example, you should enable "secure" in the cookie so that the cookie does not go to the insecure area, and restrict it to the subdomain. Otherwise, it becomes possible to steal the sessions when the user enters the insecure area. This bypassing the possibility of a Session Fixation by setting a cookie in the insecure area to be used in the secure area.
Out of privacy. Now the provider knows which site it has accessed and what information it has obtained, because it is in HTTP. If you were on HTTPS (and with HSTS Preload) only IP would be obtained, it would not even guarantee which site was accessed.
