my friend wants to make sure he visits certain websites very securely. Is booting from linux cd and visiting only https website secure, meaning only he'll have access to data? He'll be on wi-fi of home router that is WPA2-Personal as security type.
Yes, this is a good, pragmatic approach that should provide a reasonable level of security against many threats that he might face. It is not perfect (for instance, it doesn't prevent the sites he visits from including external resources over HTTP), but it's probably good enough for most purposes, including, e.g., online banking.
If he uses Firefox, if he can arrange that the copy of Firefox on his bootable Linux CD has the HTTPS Everywhere extension installed, that would be a nice addition. HTTPS Everywhere is intended to help direct you to the HTTPS version of popular sites that are accessible over HTTPS. But this may be unnecessary, depending upon his habits. For instance, if he only views one or two web sites, and is careful to always type "https" into the address bar, then HTTPS Everywhere may be unnecessary.
If he also needs to protect his privacy or anonymity, he might consider using Tor's Live CD, which comes bundled with Tor for anonymity.
P.S. See also the question on Secure Linux Desktop.
WPA2-Personal when used with weak passwords is vulnerable to brute force attacks. Using a random password of sufficient length or using a very long passphrase will provide some protection against these types of attacks. Aditionally, regularly reviewing the WiFi router's logs will aid in detection of malicious use.
Keep a written record or printed out page of the fingerprint of SSL certificates you use for high value sessions. Limit this to a very few sites and check the SSL fingerprint before performing any critical actions.
For banking and protection of financial transactions, limit transactions over a certain amount to in branch only. That will limit the liability of single transactions. Another useful precaution is to ask the bank to call your home/cell number to verify transactions over a certain amount. I agree with @gowenfawr 's suggestion to limit online capabilities to viewing account balances and not allow transfers to be initiaited from online sessions.
@DW's response is a good one. He did mention that there is the possibility of sites redirecting you to HTTPS, and if the user types in HTTP URL's directly by mistake (they are the default, after all), he will wind up with unencrypted requests. HTTPS Everywhere, as DW points out, is a big help, but it isn't perfect.
Another way to approach the problem (depending on your friend's needs) may be to get a VPS somewhere for, say, $20/month, and to run OpenVPN to that server (with split tunneling disabled, of course), and to NAT all browsing traffic through that server. This should provide some degree of safety regarding DNS resolution as well as privacy from snooping by others in the packet path between the computer and the OpenVPN VPS.
The questioner didn't say whether or not sniffer-resistance was a major concern, so this may be entirely off point, but this setup has worked well for me in the past.
It is harder to keep up-to-date with security patches when booting from CD.
Using a read-only OS will indeed protect against a number of attacks, and is particularly suitable for server deployments which use a relatively small software base that doesn't get many security updates.
But when the whole X11 and desktop and browser stack is pulled in, the frequency of security updates becomes larger, and the overhead of re-burning a CD every time an update comes out may get out-of-hand. Many banking sites also rely on flash.
It may be easier to boot from a USB stick with a physical read-only switch, or some other media that is easier to keep updated.
Google's Chrome OS, and the related Chromium OS, are relatively new, but may be a good alternative if you have suitable hardware. On supported hardware it takes advantage of TPM protection to more conveniently verify boot integrity, and has a number of other good hardening features.
Note however that there are still risks, and the project is still young. E.g. the 2011 Blackhat conference had a presentation on how extension bugs and XSS can still lead to nasty security breaches: