browser without "padlock" secure?

Can encrypted communication by a browser be assured by a certificate?

I was about to pay on the internet with a credit card when I noticed
absence of the accustomed closed padlock icon in my browser that
denotes use of https protocol that encrypts the communication. I want
to be sure my credit card info won't travel in the clear.

I phoned a tech support number that appeared on the page. They
directed me to info from the browser's menus that described a
certificate and offered that as evidence that the communication would
be "secure."

Would it?

<dmorgan-with-suffixed-"1"-ATdslextreme.com> wrote:

> Can encrypted communication by a browser be assured by a certificate?
>
> I was about to pay on the internet with a credit card when I noticed
> absence of the accustomed closed padlock icon in my browser that
> denotes use of https protocol that encrypts the communication. I want
> to be sure my credit card info won't travel in the clear.
>
> I phoned a tech support number that appeared on the page. They
> directed me to info from the browser's menus that described a
> certificate and offered that as evidence that the communication would
> be "secure."
>
> Would it?

No way to tell without more information. Specifically, things like what
browser you're using, the web site you were using, and what page you were
on there would be very helpful.

My guess would be that no, it wouldn't -- however, it's possible that the
page you were on wasn't secure, but the link you would have clicked to
transmit the information was an https: link. It's also possible that
they're using some other mechanism to give security, though I don't know
what that would be. But I can't check on either possibility as it stands.

--
ZZzz |\ _,,,---,,_ Travis S. Casey <efindel@earthlink.net>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)

On Tue, 14 Dec 2004 21:45:41 -0800, dmorgan1-with-suffixed-"1"-ATdslextreme.com wrote:
> Can encrypted communication by a browser be assured by a certificate?

NO.

> I was about to pay on the internet with a credit card when I noticed
> absence of the accustomed closed padlock icon in my browser that
> denotes use of https protocol that encrypts the communication. I want
> to be sure my credit card info won't travel in the clear.

Get the padlock locked. If the vendor is not smart enough to do that,
they are not smart enough to protect your information or care about
you losing your information.
Shoot the webmaster/vendor an email telling them why you will not do
business with them.

> I phoned a tech support number that appeared on the page. They
> directed me to info from the browser's menus that described a
> certificate and offered that as evidence that the communication would
> be "secure."

Hehehe, you need to know what a phishing exploit is. Basically,
that is where you are served up a web page which looks like the
vendor/banks site and you fill out the criminal's database not the
vendor's.

Here is one test to prove it.
The test sends you to a real bank web page
http://secunia.com/multiple_browsers...spoofing_test/

Other methods of winding up on the wrong site are misspells, or you
could have surfed through a malicious site which popped in some
malware code into your browser session and you are talking through the
criminal's site again, even if you did spell the vendor site
correctly.

http://secunia.com/ for exploits and whatnot.

My solution, I run linux operating system.
I have a seperate login account to login for credit card use.
I have a local file with the urls to click on so I cannot misspell
where I want to go.
When I logout of the account, all files are deleted and reloaded from
a pristine install. That is as safe as it gets.

I have another account for web surfing and it does the same thing.
I have yet another for reading mail. Seperate accounts for each email
account, and _never click_ a link from the email message. I cut/paste
into the browser account if I want to see it.

In article <6fjvr05oofrostndjh1vnhaa8enfoppkpo@4ax.com>, dmorgan1-with-suffixed-"1"-ATdslextreme.com wrote:
>
> I was about to pay on the internet with a credit card when I noticed
> absence of the accustomed closed padlock icon in my browser that
> denotes use of https protocol that encrypts the communication. I want
> to be sure my credit card info won't travel in the clear.

This isn't really something you should worry a lot about. More relevant
dangers are that you may be giving the card number to the wrong site
or that the card number may be stolen from a legitimate site after the
transaction has occured.

Certificates do not protect you from being tricked into giving details to the
wrong site as much as you might think. A certificate says that someone
paid someone to have their certificate work in browsers without warning
when referenced with a particular domain name. It doesn't show that the
domain name you used is really the one you wanted. If the designers of
this system were really concerned about security rather than money, there
would be a warning the first time you saw each certificate and you would
be able to save it so that when you tried to go back to that site again,
you wouldn't get another warning. When you got a warning while revisting
a site, then you would know that something was wrong.

"dmorgan1-with-suffixed-\"1\"-ATdslextreme.com" <dmorgan-with-suffixed-"1"-ATdslextreme.com> writes:
> I was about to pay on the internet with a credit card when I noticed
> absence of the accustomed closed padlock icon in my browser that
> denotes use of https protocol that encrypts the communication. I want
> to be sure my credit card info won't travel in the clear.

the locked padlock indicates that https is being used and that the
hostname in url is pretty similar to the hostname in the servers
certificate ... and presummably the issuer of the certificate
performed some validation that the person applying for the server
certificate was in some way associated with the applied for hostname
.... and that the subsequent transmission was encrypted.

this is countermeasure against evesdropping attacks and server
impersonation attacks.

the original design point for SSL was that the URL you typed would be
https/ssl and all subsequent web-pages at that site would be via SSL
.... and you were sure that the webserver you contacted with the typed
in URL was the same webserver that you are actually talking to.

the problem became that SSL placed a very heavy computational burden
on the server ... and most places have since gone to only using SSL
for the actual entry of the credit card. To get to the "pay now"
web page you typically just click on a button (rather than actually
typing the URL).

the situation is if you are dealing with a case of server
impersonation and got there w/o having the original typed URL checked
(via SSL) and all further interactions with that webserver were via
clicking buttons ... then ann impersonating webserver could create a
"pay now" button that is guaranteed to have a URL that exactly matches
what is encoding into the SSL certificate.

since the person never looks at the actual certificate and never typed
in the actual URL ... and the only thing the browser does is attempt
to match what is specified in the current URL against what is in the
provided certificate ... some number of impersonation attacks aren't
actually very hard.

as a result of the way SSL is typically deployed .... it is now
primiarly a countermeasure for evesdropping attacks and not
particularly effective against impersonation attacks.

misc. past ssl certificate postings
http://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. archeological references to e-commerce on the internet
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/95.html#13

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Looks like browsers reflect the security of a connection (ie, if it's
encrypted) in radically different (maybe unreliable?) ways.

Further investigation results:
I determined even if the browser shows no padlock icon, https *is*
being used in my situation since I can see the packets that pass
through my home router (a linux box, where I packet sniff) are going
to port 443/https. And if I look inside the packets I find SSL
protocol data. So it's an encrypted conversation, for sure.
Incidentally I originally went to www.value-name.com. But it uses html
frames, so by the time I put in credit card number I'm talking
(unknowingly) to www.secureserver.net (64.202.188.209). So that's who
I'm talking to, and I'm talking SSL.

Now, the interesting issue becomes the browsers. There's great
difference (disagreement even) between them in how they reflect this.
I observed 1) the padlock in the status bar, and 2) the security info
about the page from menus. Here are the results for 4 browsers (NO
means apparent non-encryption, YES means apparent encryption) :

Internet Explorer (on a Windows box)
padlock: NO
the place reserved for the padlock on the status bar is empty,
characteristic of normal http browsing
menu info: YES
file/properties indicates "Protocol: http Type: file Connection: SSL
3.0 RC4 with 128 bit... Address (URL): http://www.value-name.com/ ..."

Firefox (on a Windows box)
padlock: NO
none appears on the status bar or elsewhere
menu info: NO
tools/pageinfo/security indicates "Web Site Identity Not Verified" and
"Connection Not Encrypted The web site www.value-name.com does not
support encryption for the page you are viewing." [Of course, the
actual page I'm viewing at this point is www.secureserver.net, not
value-name]

Mozilla (on a linux box)
padlock: NO
the padlock appears in the status bar, shown unlocked
menu info: NO
shows just the same as did Firefox ("not encrypted")

Konquerer (on a linux box)
padlock: YES
appears in the status bar, shown locked
menu info: MAYBE
view/security "Some of this document is secured with SSL but the main
part is not."

I'm interested in any wisdom on when/why/where browsers-and-servers
decide to switch to https on port 443 rather than just plain http on
port 80. What makes them use SSL? And, what do browsers think they are
depicting when they try to tell us about security with their cryptic
padlocks and differing menu info?