RE: Tls1.2 Problem with client certificate and RSA_verify
Thanks Steve! Unfortunately your hint couldn't help me. I know that in TLS 1.2 the hash and signature algorithms can be chosen during the handshake. I chose to use Sha256 with RSA for the signature, and therefore adding the corresponding algorithm ids in front of the signature. In Wireshark my Client Certificate Verify message (including the record layer header) looks like following: 16 03 03 00 88 0f 00 00 84 04 01 00 80 b4 ee c0 0010 8a 35 79 0d 97 7d f0 82 e6 69 3d 7d 66 a7 58 11 0020 e5 9c 86 c1 9e 18 0c a0 94 37 2e 2b d2 08 9a 69 0030 0f 14 22 42 5c 66 b8 cb 8f dd 85 6d 85 82 f7 5e 0040 48 84 05 b5 ca e1 7b 67 d2 08 da 8c ec 55 a2 49 0050 5e e6 eb f4 c2 ae b9 6e 0c 9b 43 2a 78 92 16 97 0060 8a ee 1e 19 57 10 7c dc d3 f5 74 21 7c cc b8 e4 0070 cb f2 c0 2d fe 4f c7 5f 33 cb 1a 55 da 6c 6a 76 0080 6a 94 ad 64 f5 b0 d1 d2 0e 9b 15 8d b7 The first 5 bytes are the record layer header (handshake message, protocol version TLS 1.2, length 0x88 byte). Next comes 0x0F as handshake message type (certificate verify), then 0x84 as the length, then 0x0401 for SHA256 hash signed with RSA, followed by the length of the signature and the signature itself. From this point of view to me it looks exactly like the message I observed on a conversation between an openssl client and server (both TLS1.2). So where else can the problem be? I also debugged the openssl-server when receiving the message above. The server recognized the correct hash and signature algorithms, but while following the functions to the point where the signature shall be verified, I will come to a point where for some reason a wrong function is called. The code says it wants to call RSA_verify(), but CMS_RecipientInfo_type() is called instead and returns a value that (of course) does not correspond with the function that should have been called. It would really help me a lot if I could debug the server correctly so that I could compare my hash/signature better with the one computed by the openssl server. Did anyone see that behavior before? Regards, Thorsten -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Friday, July 27, 2012 6:47 PM To: openssl-users@openssl.org Subject: Re: Tls1.2 Problem with client certificate and RSA_verify On Fri, Jul 27, 2012, Albers, Thorsten wrote: Hi, I have a problem with the openssl s_server (v1.0.1c) when requesting a client certificate. I'm developing my own TLS 1.2 implementation (for embedded platforms), and I'm stuck with a problem with using the client certificate. I already implemented TLS 1.0 earlier, so it's not completely new for me, and it worked fine even with client certificates. My current implementation can handle TLS 1.2 handshakes without client authentication, as well as TLS 1.0 with or without client authentication. When I try to connect to the openssl server, the handshake goes as far as the client having sent its messages up to (including) 'change cipher spec'. But then the server sends an alarm (decrypt error). The openssl server console tells me some strange error: ACCEPT bad gethostbyaddr depth=1 CN = TestAndDevRootAuthority verify return:1 depth=0 CN = MyClient verify return:1 1696:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:.\crypto\asn1\asn1_lib.c:142: 1696:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:.\crypto\asn1\tasn_dec.c:1306: 1696:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\crypto\asn1\tasn_dec.c:381:Type=X509_SIG 1696:error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad signature:.\ssl\s3_srvr.c:3049: 1696:error:140780E5:SSL routines:SSL23_READ:ssl handshake failure:.\ssl\s23_lib.c:131: ACCEPT For previous versions of TLS the signature for RSA is a raw MD5+SHA1 concatenation. For TLS 1.2 it is the DigestInfo structure instead using whatever digest is appropriate. That error looks like OpenSSL is trying to interpret an MD5+SHA1 signature as a DigestInfo and choking on it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ ___ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: create certificate request programmatically using OpenSSL API
GOST is not a block cipher, it's the acronym for GOsudarstvennyi
STandard, which means State Standard. It's not dedicated to cryptography.
Speaking of GOST standard is redundant, but clearer for non russian
locutors.
There's a block cipher (poorly) defined as a GOST standard, referenced
GOST 28147-89. Attempts to be adopted as an ISO standard have failed.
The S-Box to use is not defined in the standard, whence 2 compliant
implementations can be non interoperable.
There's also a hash algorithm defined as a GOST standard, referenced
GOST R 34.11-94 or GOST 34.311-95, using GOST 28147-89 inside. GOST
R 34.11-94 in itself is also useless because of the lack of S-Box
standard. The RFC 4357 defines 2 S-Boxes.
And finally there's a digital signature defined as a GOST standard,
referenced GOST R 34.10-94 and superseded by GOST R 34.10-2001
(RFC5832), consider it similar to ECDSA. It uses GOST R 34.11-94 to
hash data (just as {EC}DSA uses SHA{1,2*}).
--
Erwann ABALEA
Le 28/07/2012 21:31, Jeffrey Walton a écrit :
On Fri, Jul 27, 2012 at 9:00 AM, Abyss Lingvo xidex...@yahoo.com wrote:
Hi all!
The last problem is how to create GOST key pair for certificate.
It is clear how to create RSA keys.
Sample is here : http://www.openssl.org/docs/crypto/EVP_PKEY_keygen.html
#include openssl/evp.h
#include openssl/rsa.h
EVP_PKEY_CTX *ctx;
EVP_PKEY *pkey = NULL;
ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
if (!ctx)
/* Error occurred */
if (EVP_PKEY_keygen_init(ctx) = 0)
/* Error */
if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048) = 0)
/* Error */
/* Generate key */
if (EVP_PKEY_keygen(ctx, pkey) = 0)
/* Error */
Unfortunately there is no EVP_PKEY_GOST constant and I can't create EVP_PKEY
containing GOST key pair.
Does anybody know how to create GOST key pair?
GOST is a block cipher. It uses a symmetric key, not public/private keys.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: create certificate request programmatically using OpenSSL API
Hi Jeff There are two GOST algorithms. GOST 28147-89 is for symmetric block cyphering and GOST R 34.10-2001 for asymmetric cyphering and digital signing. OpenSSL support both algorithms. I mean GOST R 34.10-2001 here. Best Regards
Re: 9GB libcrypto.a in openssl-1.0.1c
We saw this earlier with another build product. I think the 'ar' program in some of these build environments (oh all right IDEs) is just adding entries to an existing libcrypto.a. I suspect that the build environment extracts 'libcrypto.a' plus some other binaries out of some source control system. Over time such 'libraries' get a little large (is there an emoticon for irony?). I suggest one of at least three options to remedy this: EITHER 1. Removing the libcrypto.a file from the source control system altogether. OR 2. Modifying the source control system so it knows to only check out source files (rather than binaries) prior to a build OR 3. Adding make clean amd rm Makefile before running Configure in the build environment. 2 and 3 are preferable as there may be other files getting large as a result of the build adding object files to existing (that is checked out) binaries. Good luck Dennis and others. Jeremy Hunt Zack Weinberg wrote: On Sun, Jul 29, 2012 at 11:00 AM, Dennis Clarke dcla...@blastwave.org wrote: After a build of openssl-1.0.1c on Solaris 10 with the Sun Studio 12 compilers I was very surprised to see this : # ls -l libcrypto.a -rw-r--r-- 1 root root 9908820968 Jul 17 19:47 libcrypto.a It's not supposed to be that large. I've never built on Solaris, but this OSX build is typical as far as I can tell: -rw-r--r-- 1 root admin 3136968 May 10 09:28 /opt/local/lib/libcrypto.a I'm inclined to suspect something funny with the Sun Studio compilers. I would be interested to know what size libcrypto.a prints for you. That will indicate which of the object files in the library is/are responsible for its overall size. zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client cert, unverified in Firefox BUT trusted in Chrome
On Mon, Jul 30, 2012 at 12:17 AM, Saurabh Pandya er.saurabhpan...@gmail.com wrote: You need to Add Root CA of your client certificate to BOTH, Chrome anf Firefox Saurabh, thanks. The strange thing is, both browsers do have the Root CA. I am still trying to fiddle with details of the CSR and signing of the certs. Perhaps that is making a difference. Best regards, -Tom __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Tls1.2 Problem with client certificate and RSA_verify
On Mon, Jul 30, 2012, Albers, Thorsten wrote:
Thanks Steve! Unfortunately your hint couldn't help me. I know that in TLS
1.2 the hash and signature algorithms can be chosen during the handshake. I
chose to use Sha256 with RSA for the signature, and therefore adding the
corresponding algorithm ids in front of the signature. In Wireshark my
Client Certificate Verify message (including the record layer header) looks
like following:
16 03 03 00 88 0f 00 00 84 04 01 00 80 b4 ee c0
0010 8a 35 79 0d 97 7d f0 82 e6 69 3d 7d 66 a7 58 11
0020 e5 9c 86 c1 9e 18 0c a0 94 37 2e 2b d2 08 9a 69
0030 0f 14 22 42 5c 66 b8 cb 8f dd 85 6d 85 82 f7 5e
0040 48 84 05 b5 ca e1 7b 67 d2 08 da 8c ec 55 a2 49
0050 5e e6 eb f4 c2 ae b9 6e 0c 9b 43 2a 78 92 16 97
0060 8a ee 1e 19 57 10 7c dc d3 f5 74 21 7c cc b8 e4
0070 cb f2 c0 2d fe 4f c7 5f 33 cb 1a 55 da 6c 6a 76
0080 6a 94 ad 64 f5 b0 d1 d2 0e 9b 15 8d b7
The first 5 bytes are the record layer header (handshake message, protocol
version TLS 1.2, length 0x88 byte). Next comes 0x0F as handshake message
type (certificate verify), then 0x84 as the length, then 0x0401 for
SHA256 hash signed with RSA, followed by the length of the signature and the
signature itself. From this point of view to me it looks exactly like the
message I observed on a conversation between an openssl client and server
(both TLS1.2). So where else can the problem be?
The problem you mentioned indicates that there is a bug in the RSA signature
format itself and not the TLS message structure. Without the corresponding
public key it is impossible to analyse that signature though.
I also debugged the openssl-server when receiving the message above. The
server recognized the correct hash and signature algorithms, but while
following the functions to the point where the signature shall be verified,
I will come to a point where for some reason a wrong function is called. The
code says it wants to call RSA_verify(), but CMS_RecipientInfo_type() is
called instead and returns a value that (of course) does not correspond with
the function that should have been called. It would really help me a lot if
I could debug the server correctly so that I could compare my hash/signature
better with the one computed by the openssl server. Did anyone see that
behavior before?
This sounds like the debugger is getting confused. Try adding a debugging
printf in the RSA_verify function to check it is being called.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Certificate and Certificate request (Using API)
On Fri, Jul 27, 2012 at 08:05:58AM -0700, Sanford Staab wrote: It really looks to me like the openssl documentation needs improvement as well as a better tool besides CA.pl to help people use openssl in common scenarios. I suspect there is a strong demand for creative private CA support and we should have a friendly script or cookbook for this available somewhere. Fixing this will relieve you guys of answering all these inquiries via email. TinyCA has, so far, sufficed for my modest needs. http://tinyca.sm-zone.net/ -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpOYxbnU7YZ2.pgp Description: PGP signature
Re: [openssl-users] Re: create certificate request programmatically using OpenSSL API
On Mon, Jul 30, 2012 at 5:15 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: GOST is not a block cipher, it's the acronym for GOsudarstvennyi STandard, which means State Standard. It's not dedicated to cryptography. My apologies. I thought you were referring to the GOST block cipher. (I've never used it, but knew its been part of Crypto++ for some time: http://www.cryptopp.com/docs/ref/class_g_o_s_t.html). Jeff Le 28/07/2012 21:31, Jeffrey Walton a écrit : On Fri, Jul 27, 2012 at 9:00 AM, Abyss Lingvo xidex...@yahoo.com wrote: Hi all! The last problem is how to create GOST key pair for certificate. It is clear how to create RSA keys. Sample is here : http://www.openssl.org/docs/crypto/EVP_PKEY_keygen.html #include openssl/evp.h #include openssl/rsa.h EVP_PKEY_CTX *ctx; EVP_PKEY *pkey = NULL; ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); if (!ctx) /* Error occurred */ if (EVP_PKEY_keygen_init(ctx) = 0) /* Error */ if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048) = 0) /* Error */ /* Generate key */ if (EVP_PKEY_keygen(ctx, pkey) = 0) /* Error */ Unfortunately there is no EVP_PKEY_GOST constant and I can't create EVP_PKEY containing GOST key pair. Does anybody know how to create GOST key pair? GOST is a block cipher. It uses a symmetric key, not public/private keys. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strange results after setting utf8 -subj in openssl ca command
Look at this example: $openssl x509 -subject -nameopt oneline,-esc_msb,utf8 -noout -in 13/13_cert.pem ... CN = 13#ტესტერიN13 $openssl x509 -subject -noout -in 13/13_cert.pem ... CN=13#\xE1\x83\xA2\xE1\x83\x94\xE1\x83\xA1\xE1\x83\xA2\xE1\x83\x94\xE1\x83\xA0\xE1\x83\x98N13 This certificate was signed by openssl ca without changing subject, and openssl req did not use BMPString and UCS-2 in this case. CN string contains Georgian letters but numbers are in ASCII so it is UTF-8 in fact. So why openssl ca decides to use BMPString format? Looks like 1-byte code strings can be used without violating ASN.1 standard - Original Message - From: Dave Thompson dthomp...@prinpay.com To: openssl-users@openssl.org Cc: Sent: Monday, July 30, 2012 6:47 AM Subject: RE: strange results after setting utf8 -subj in openssl ca command From: owner-openssl-us...@openssl.org On Behalf Of Pica Pica Contact Sent: Saturday, 28 July, 2012 14:41 Note that X.509 certs (and ASN.1 generally) don't actually support UTF8. They support several 1-byte codes (some now obsolete), BMPString which is 2-byte UCS-2, and UniversalString which is 4-byte UCS-4. I believe OpenSSL selects the smallest of these into which the specified (Unicode) codepoints fit, which in this case is UCS-2. After adding -nameopt oneline,-esc_msb,utf8 result looks fine That should translate the Unicode to UTF8 and output it, and assuming your terminal handles UTF8 then yes it will be good I call X509_NAME_oneline() function inside my application to get CN string, and application fails to convert number from CN field to integer, because X509_NAME_oneline() returns /CN=\x003\x000\x000\x000\x000\x00# instead of CN=3# I'm pretty sure _oneline is what x509 -text without -nameopt uses. Probably I should use X509_NAME_print_ex(), Or if you only want CN, you could get the raw CN item and its value out of the name structure which in OpenSSL is STACK_OF(X509_NAME_ENTRY). but I have doubts if this string encoding is correct and how it would work with other software. For example, certtool from GnuTLS outputs subject string in this way: $ certtool -i --infile 3.pem ...skipped... Subject: CN=#003300300030003000300023044204350441044210e210d410e110e24e2d56fd ...skipped... That apparently is dumping the UCS-2 bytes. Compare to above. There are no such problems in openssl req, I can set UTF8 strings with numbers in certificate requests and resulting certificate is ok for me, but I need to ignore subject from certificate requests and set my own value Is it possible to fix openssl ca command somehow to encode numbers in UTF8 strings as strings, not numbers? 'ca' can only encode ASN.1 strings in the ways defined by ASN.1. You must decode them accordingly. Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strange results after setting utf8 -subj in openssl ca command
On Sun, Jul 29, 2012, Dave Thompson wrote: Note that X.509 certs (and ASN.1 generally) don't actually support UTF8. They support several 1-byte codes (some now obsolete), BMPString which is 2-byte UCS-2, and UniversalString which is 4-byte UCS-4. I believe OpenSSL selects the smallest of these into which the specified (Unicode) codepoints fit, which in this case is UCS-2. There is a UTF8String type which has been about for some time. OpenSSL for certificate requests uses the smallest of a set of types determined by the string_mask option in openssl.cnf. This is set to utf8only in OpenSSL 1.0.0 and later. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: RSA PRIVATE KEY, CERTIFICATE REQUEST, and CERTIFICATE
I am trying to set it up with PayPal to accept credit cards with a shopping cart on my website. I had gotten another response that all I needed to send them was the certificate. Thanks for your help! Rita S. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Saurabh Pandya Sent: Saturday, July 28, 2012 9:34 AM To: openssl-users@openssl.org Subject: Re: RSA PRIVATE KEY, CERTIFICATE REQUEST, and CERTIFICATE On 7/28/12, Rita Rex Smith ritarexsm...@gmail.com wrote: I am just getting started trying to figure out how to set up an SSL certificate and key with PayPal to use for encrypted payments on my website. I am totally confused as to what I need to upload to them and how to figure out if it is correct or not. I am familiar with programming, but I am having a lot of trouble figuring this out. I would appreciate your help! Do you want to set up Certificate signing request ?? And get is signed by Paypal ?? Thanks! Rita Smith ritarexsm...@gmail.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: strange results after setting utf8 -subj in openssl ca command
From: owner-openssl-us...@openssl.org On Behalf Of Pica Pica Contact Sent: Monday, 30 July, 2012 13:47 Look at this example: snip This certificate was signed by openssl ca without changing subject, and openssl req did not use BMPString and UCS-2 in this case. CN string contains Georgian letters but numbers are in ASCII so it is UTF-8 in fact. You're probably right. (To be positive, I'd check the req directly, not the x509 into which it is copied, because the copy *could* change the encoding as long as it doesn't change the canonical value. But I'd be surprised if it did. OTOH I've been surprised before.) On rechecking I am reminded there *is* an ASN.1 type UTF8String, which I had forgotten when I answered before. Sorry for the misstatement. So why openssl ca decides to use BMPString format? Looks like 1-byte code strings can be used without violating ASN.1 standard So that is a valid question. (Well, pedantically UTF8 is a variable-byte code, not a 1-byte code, but it's clear what you mean.) I've definitely looked at some code, but I don't remember exactly where (or when), that chooses based on the chars needed, something like: if all are printable use PrintableString, else if all are 1-byte use GeneralString, else if all are 2-byte/BMP use BMPString, else use UniversalString. I'm guessing logic like that was used, and it wouldn't choose UTF8 even though UTF8 can represent all Unicode. You'll probably have to read the source or debug, unless someone else chips in. If you don't need all the features of 'ca', like database and CRLs, you could try 'x509 -req -CA*' and see if it's different on this point. That is a separate implementation of nearly-identical function. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Tls1.2 Problem with client certificate and RSA_verify
From: owner-openssl-us...@openssl.org On Behalf Of Albers, Thorsten Sent: Monday, 30 July, 2012 03:43 snip I also debugged the openssl-server when receiving the message above. The server recognized the correct hash and signature algorithms, but while following the functions to the point where the signature shall be verified, I will come to a point where for some reason a wrong function is called. The code says it wants to call RSA_verify(), but CMS_RecipientInfo_type() is called instead and returns a value that (of course) does not correspond with the function that should have been called. It would really help me a lot if I could debug the server correctly so that I could compare my hash/signature better with the one computed by the openssl server. Did anyone see that behavior before? Is it really calling CMS_blah, or is your debugger just displaying the location as CMS_blah + x? Most symbolic debuggers, if you have some code with symbols and some without, and you're 'running' (i.e. your PC is in) code without symbols, will just take some symbol it considers 'handy' and use that plus an offset. If you are at the direct call to RSA_verify from ssl3_get_cert_verify which is at s3_srvr.c line 3057 in 1.0.1c, and your libssl has symbols but your libcrypto doesn't, I would expect debugger display like that. But, you shouldn't be executing that call. For TLS1.2, you should be taking the branch at line 3023 et seq which instead uses EVP_Verify*, and if you step through EVP_VerifyFinal it should reach a point where it calls through a function pointer to RSA_verify, so you wouldn't see that name in your source. And EVP_* should be in the same libcrypto as RSA_*, unless you did partial rebuild(s) or some kind of linking that mixed pieces from different sources. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: code/function for Round Trip Time
Fiddler. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Santosh N Dumbre Sent: Monday, July 30, 2012 12:14 AM To: openssl-users@openssl.org Subject: code/function for Round Trip Time H i, Is there any function available in Open SSL library to measure Round Trip Time for TCP and UDP communication ? Any help reagrding programmatically measuring Round Trip Time is highly appreciated. Kindly reply. Thanks Regds, Santosh. 91-9890688783 _ Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com. iGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE please visit www.igate.com.
