| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
< 인라인 구성 >
< 아웃오브패스 구성 >
| [가상화] Understanding VMware vShield Endpoint And Agentless Malware Protection (1) | 2010.11.22 |
|---|---|
| [Firewall] paloalto network firewall (0) | 2010.11.19 |
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
September 10, 2010
When I wrote my analysis on VMware’s VMworld 2010 announcements earlier this week, I didn’t cover a product which piqued my interest. It is about VMware’s moves to beef up virtualization and cloud security through their vShield offering. I decided to wait because I wanted to talk to one of VMware’s partners, Trend Micro, before digging deeper into it. Now that I have spoken to folks at Trend Micro and learned how they could integrate their security product into vSphere 4.1, it is time for my brief analysis of VMware’s endpoint security.
The Problem:
Of many security issues surrounding the IT, the endpoint security is very important and crucial for regulatory compliance requirements. Traditionally, endpoint security used the client/server model where every end point device (servers, desktops, laptops, etc..) had a client installed on all these devices and centrally managed by the IT security. The “hefty” client will monitor the device, analyze the content, process and act based on the set of rules. This approach was not efficient but there was no better approach to the problem. As the IT moved to virtualized environment and cloud, this problem only became bigger. Not only this approach increased the complexity of endpoint security on virtualized and cloud environments but, also, had an impact on the overall performance. Some of the problems with the client/server approach to endpoint security are
Clearly, even though the client/server approach offers reliable endpoint security, it is not an efficient way to do security in virtualized environments. There was definitely a need for a better approach. So far, the virtualization vendors were relying on the third party providers in the ecosystem to fill the gap and third party providers were waiting for the virtualization vendors to offer something better because there is not much they can do with the client/server model.
VMware’s approach to endpoint security:
At VMworld 2010 last week, VMware announced the first step towards having a more efficient endpoint security model. The VMware vShield Endpoint solution for vSphere 4.1 and View 4.5 environments offered library and APIs for integrating partner security appliances that can introspect into file activity at the hypervisor layer. Imagine taking an endpoint security appliance from a vendor, putting it into the virtualized/cloud environment and tapping into their APIs to do all the protection without installing any agent on the virtual machines. This simple and elegant approaches vastly reduces the performance impact on the virtual environment and, may, even offer considerable cost savings in terms of license fees, etc.. Not only that it simplifies the compliance auditing processes making clouds more palatable to enterprise customers with heavy compliance requirements.
vShield Endpoint plugs directly into vSphere and it has the following three components to carry out the protection as mentioned in the above paragraph.
vShield Endpoint monitors the file events on virtual machines through its “thin agents” and notifies the anti-virus/malware engine vial EPSEC, which scans and returns the result. The same approach also supports regularly schedules partial and full scans of VMs. In the event of any exploit/vulnerability/attack, admins can specify the actions through the management tools integrated into vCenter/vCloud Director and these actions will be carried out on the affected virtual machines by vShield Endpoint.
Conclusion:
In my opinion (keep in mind I am not a security guru but someone who only observes them and talk to them), this is a very elegant solution by VMware to tackle this problem. Not only they made it simple and easy, they also help their customers achieve increased performance with their implementation of VMware virtualization/cloud. I am pretty sure other virtualization vendors will soon come up with similar solutions. In fact, when I spoke to Trend Micro, they told me that they will support other platforms with agent-less endpoint security once they offer APIs similar to what VMware is offering. Next week, I will build upon this and talk about how Trend Micro tapped into vShield Endpoint to offer powerful malware protection without “any” impact on the performance.
| [DDoS] DDoS 제품 구성별 특징 (0) | 2011.06.10 |
|---|---|
| [Firewall] paloalto network firewall (0) | 2010.11.19 |
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
Legacy port-based firewalls are ineffective at identifying and controlling applications because of their reliance on port and protocol as a means of traffic classification. Most applications are capable of bypassing using a variety of techniques such as tunneling another application, sneaking across port 80, hopping ports or using SSL. The lack of visibility and control means that port-based firewalls are no longer the central control point of the security infrastructure.
In order to restore the firewall as the strategic center of the security infrastructure, Palo Alto Networks developed a traffic classification technology that accurately identifies the applications, irrespective of port, protocol, SSL, or evasive tactic. The result is App-ID™, a patent-pending traffic classification technology that enables administrators to determine exactly which applications are running on their network.
Whereas port-based firewalls use only one mechanism of traffic classification, App-ID goes well beyond any other network security technology available, inspecting all of the traffic passing through the firewall, with one or more of identification techniques – including application protocol detection and decryption, application protocol decoding, application signatures, and heuristic analysis. The application identity is then used as the basis of the security policy.
Now, rather then react to the discovery of a strange application by summarily blocking it, the administrator can take a more balanced and informed approach by learning more about the application and then safely enabling its usage or blocking it based on the security risks. With App-ID, IT can now:
As enterprises continue to use Internet- and web-centric applications to aid expansion and increase efficiencies, visibility into what users are doing on the network becomes increasingly important. Dynamic IP addressing across both wired and wireless networks, and remote access by employees and non-employees alike have made the use of IP addresses an ineffective mechanism for monitoring and controlling user activity. Unfortunately, today’s port-based firewalls rely heavily on IP addresses as a means of identifying and controlling user activity.
Palo Alto Networks User-ID technology addresses the lack of visibility into user activity by seamlessly integrating with enterprise directory services (Active Directory, LDAP, eDirectory) to dynamically link an IP address to user and group information. In Citrix and terminal services environments, User-ID associates the individual user with their network activity, enabling IT to deploy granular security policies. Integration with other 3rd party repositories is enabled by an XML API.
With visibility into user activity, enterprises can monitor and control applications and content traversing the network based on the user and group information stored within the user repository. User-ID enables IT to:
User-ID gives an administrator complete visibility into the application activity at a user level, not just an IP address level and in so doing, addresses a key requirement in regaining control over the applications traversing the network. When used in conjunction with App-ID, and Content-ID technologies, User-ID enables IT organizations to enjoy unmatched policy-based visibility and control over users, applications and content.
Enterprise networks are rife with applications that can evade detection. Common methods include dynamically hopping ports, re-using other ports, emulating other applications or tunneling inside SSL. The use of evasive applications has not gone unnoticed by attackers as they increasingly use these invisible applications to transport threats past the firewall. Content-ID melds a uniform threat signature format, stream-based scanning and a comprehensive URL database with elements of application visibility to detect and block a wide range of threats, control non-work related web surfing, and limit unauthorized file and data transfers.
Traffic is normalized to eliminate invalid and malformed packets, while TCP reassembly and IP de-fragmentation is performed to ensure the utmost accuracy and protection despite any attack evasion techniques.
Content-ID takes full advantage of Palo Alto Networks SP3 Architecture to deliver high performance threat prevention without impeding traffic.
| [DDoS] DDoS 제품 구성별 특징 (0) | 2011.06.10 |
|---|---|
| [가상화] Understanding VMware vShield Endpoint And Agentless Malware Protection (1) | 2010.11.22 |
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
Voice Over IP | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Voice-over-IP Overview
A VoIP system consists of a number of different components: Gateway/Media Gateway, Gatekeeper, Call agent, Media Gateway Controller, Signaling Gateway and a Call manager
Megaco (H.248)
Interested in more details about testing this protocol?
MGCP
MG=Media Gateway
The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection. The Call Agent may send either of the Audit commands to the gateway. The Gateway may send a RestartInProgress command to the Call Agent.
The command line is composed of:
These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e., the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.
Interested in more details about testing this protocol?
http://www.rfc-editor.org/rfcsearch.html RFC 2045 - 2049 This set of standards, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefine the format of messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US-ASCII. The initial standard in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. RFC 2046 defines the general structure of the MIME media typing system and defines an initial set of media types. The third standard, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth standard, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final standard, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. The first standard in this set, RFC 2045, defines a number of header fields, including Content-Type. The Content-Type field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute/value notation. The ordering of parameters is not significant. In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio". For this reason, registered subtypes of "text", "image", "audio", and "video" should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types. Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize. MIME's Content-Type header field and media type mechanism has been carefully designed to be extensible, and it is expected that the set of media type/subtype pairs and their associated parameters will grow significantly over time. Several other MIME facilities, such as transfer encodings and "message/external-body" access types, are likely to have new values defined over time. In order to ensure that the set of such values is developed in an orderly, well-specified, and public manner, MIME sets up a registration process which uses the Internet Assigned Numbers Authority (IANA) as a central registry for MIME's various areas of extensibility. The registration process for these areas is described in RFC 2048.
Interested in more details about testing this protocol?
RVP over IP
A one byte field containing the length of the header (protocol code and the entire RVP/IP message). The length field allows recognition of message boundaries in a continuous TCP data stream. Protocol code Identifies the RVP/IP protocol:
RVP/IP messages
Operation code
Parameter count
Type
RVP signalling data packets always begin with a length byte immediately after the RVP/IP encapsulation header. The packets contain two classes of data, either raw digital telephone signalling packets or high-level RVP session commands. Session commands are differentiated from raw signalling data by adding an offset of 130 in the "Message Length" field. All raw signalling data has a true length field of less than or equal to 128. The true length of a session command message is calculated by subtracting 130 from the length field. For all session commands, the Command Code (one-byte) follows the message length field. Bit seven of the command code is considered the "ACK" bit. All other bits in this field are part of the command code itself. Voice Data Packets
Protocol RVP/IP voice data Interested in more details about testing this protocol?
Internet draft: http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-04.txt SAP is an announcement protocol that is used by session directory clients. A SAP announcer periodically multicasts an announcement packet to a well-known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement can also be potential recipients of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local. The following is the format of the SAP data packet.
V: Version Number A: Address Type R: Reserved T: Message Type E: Encryption Bit C: Compressed Bit Authentication Length Message Identifier Hash Originating Source Timeout Payload Type Payload Version number (V) Padding Bit (P) Authentication Type (Auth)
Interested in more details about testing this protocol?
RFC 2327 ftp://ftp.isi.edu/in-notes/rfc2327.txt The Session Description Protocol (SDP) describes multimedia sessions for the purpose of session announcement, session invitation and other forms of multimedia session initiation. On Internet Multicast backbone (Mbone) a session directory tool is used to advertise multimedia conferences and communicate the conference addresses and conference tool-specific information necessary for participation. The SDP does this. It communicates the existence of a session and conveys sufficient information to enable participation in the session. Many of the SDP messages are sent by periodically multicasting an announcement packet to a well-known multicast address and port using SAP (session announcement protocol). These messages are UDP packets with a SAP header and a text payload. The text payload is the SDP session description. Messages can also be sent using email or the WWW (World Wide Web). The SDP text messages include:
SDP messages are text messages using the ISO 10646 character set in UTF-8 encoding.
Interested in more details about testing this protocol?
SIP Session Initiation Protocol (SIP) is a application layer control simple signalling protocol for VoIP implementations using the Redirect Mode. SIP is a textual client-server base protocol and provides the necessary protocol mechanisms so that the end user systems and proxy servers can provide different services:
SIP addresses (URL) can be embedded in Web pages and therefore can be integrated as part of powerful implementations (Click to talk, for example). SIP using simple protocol structure, provides the market with fast operation, flexibility, scalability and multiservice support. SIP provides its own reliability mechanism. SIP creates, modifies and terminates sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate using multicast or using a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. It supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. It is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility which is based on the use of a unique personal identity SIP supports five facets of establishing and terminating multimedia communications:
SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully-meshed interconnection instead of multicast. Internet telephony gateways that connect Public Switched Telephone Network (PSTN) parties can also use SIP to set up calls between them. SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as RSVP, RTP RTSP, SAP and SDP. However, the functionality and operation of SIP does not depend on any of these protocols. SIP can also be used in conjunction with other call setup and signalling protocols. In that mode, an end system uses SIP exchanges to determine the appropriate end system address and protocol from a given address that is protocol-independent. For example, SIP could be used to determine that the party can be reached using H.323 to find the H.245 gateway and user address and then use H.225.0 to establish the call. SIP Operation SIP messages can be transmitted either over TCP or UDP Protocol header structure. Request Messages
Method
Request-URI SIP version Response Message
SIP version Status-code Reason-phrase Typical SIP Calls
Interested in more details about testing this protocol?
IETF draft: http://www.ietf.org/internet-drafts/draft-huitema-sgcp-v1-02.txt Simple Gateway Control Protocol (SGCP) is used to control telephony gateways from external call control elements. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. The SGCP assumes a call control architecture where the call control intelligence is outside the gateways and is handled by external call control elements. The SGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. The SGCP implements the simple gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are five types of commands:
The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection. All commands are composed of a Command header, optionally followed by a session description. All responses are composed of a Response header, optionally followed by a session description. Headers and session descriptions are encoded as a set of text lines, separated by a line feed character. The headers are separated from the session description by an empty line. The command header is composed of:
The command line is composed of:
These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e. the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.
Interested in more details about testing this protocol?
Cisco protocol Skinny Client Control Protocol (SCCP). Telephony systems are moving to a common wiring plant. The end station of a LAN or IP- based PBX must be simple to use, familiar and relatively cheap. The H.323 recommendations are quite an expensive system. An H.323 proxy can be used to communicate with the Skinny Client using the SCCP. In such a case the telephone is a skinny client over IP, in the context of H.323. A proxy is used for the H.225 and H.245 signalling. The skinny client (i.e. an Ethernet Phone) uses TCP/IP to transmit and receive calls and RTP/UDP/IP to/from a Skinny Client or H.323 terminal for audio. Skinny messages are carried above TCP and use port 2000. The messages consist of Station message ID messages. They can be of the following types:
Interested in more details about testing this protocol? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [가상화] Understanding VMware vShield Endpoint And Agentless Malware Protection (1) | 2010.11.22 |
|---|---|
| [Firewall] paloalto network firewall (0) | 2010.11.19 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
| [DB] DB 암호제품 보안요구사항 (0) | 2010.05.27 |
What actually is VMsafe and the VMsafe API?
By Michael Haines, Sr. vCloud Architect (Security)
Today, security vendors, such as Trend Micro, McAfee and others are now entering the virtualization market and are looking for ways to develop and integrate their existing solutions (antivirus, personal firewall, intrusion detection, intrusion prevention, anti-spam, URL filtering, and etc…) to VMware's ESX Server while trying to differentiate themselves from the competition.
So, I am sure you have heard a great deal about VMsafe and in particular what the VMsafe API is, right? This word 'VMSafe API' gets bounded around way too often for my liking! So what is VMsafe and the VMSafe API?
When I think of VMsafe, I think of this as more of a partner ecosystem program delivered by VMware. That is to say, what we have created and offer as part of this ecosystem program are three sets of distinct Application Programming Interfaces (APIs) that can be used by ISVs and developers to develop and build security applications and solutions for the virtual environment. I might add this is not for the faint hearted! These APIs are split into three main areas:
- vCompute (CPU and Memory) API
- vNetwork Appliance (DVFilter) API
- VDDK API (for disk block inspection)
The vCompute CPU and Memory API.
So what does the vCompute CPU and Memory Inspection API do? At its most basic form, this API includes features that you can use for developing security applications that inspect memory access and CPU states before any code is actually executed.
The vNetwork Appliance (DVFilter) API
So what does the vNetwork Appliance (DVFilter) API do? This API enables you to provide a solution to protect network packet streams. With the DVFilter you can create network packet filters that you insert into the virtual packet stream. This network packet filter is inserted between the vNIC and virtual switch (vSwitch). There are one of two possible agents that can be used. These agents are referred to as the fast-path agent and slow-path agent, which make up the "filter". I’ll write more on the fast-path and slow-path agents in a future blog. One of the key messages here is that the vNetwork Appliance APIs are not just for security, we envision a lot more use cases moving forward. In fact, you may not be aware of this, but Lab Manager was the first product to use DVFilter.
The VDDK API
So what does the VDDK API do? The Virtual Disk Development Kit is a collection of C libraries, code samples, utilities, and documentation that enable a developer who is creating applications to manage virtual storage. Yes, it’s an API and Software Development Kit (SDK). The Virtual Disk Development Kit includes the Virtual Disk API library functions, VMware disk utilities (which include the disk mount and virtual disk manager) and documentation. The primary audience for VDDK are ISVs who develop, for example, anti-virus security products.
So, how does one get access to the VMsafe partner ecosystem program? Well, firstly this program itself is controlled in terms of which partners can get to it and use it. Today, only one API (VDDK) that is part of the VMsafe program is a public API. That is to say that the vCompute and vNetwork are not public APIs. As I mentioned earlier, these APIs are not end user APIs but rather are intended for security partners. For more information on these security partner APIs, go to VMware's Advanced Developer Portal. For more information on VMSafe in general, please visit us here.
| [Firewall] paloalto network firewall (0) | 2010.11.19 |
|---|---|
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
| [DB] DB 암호제품 보안요구사항 (0) | 2010.05.27 |
| [기타] reCAPTCHA (1) | 2009.09.08 |
A number of operations in the TLS record and handshake layer require a keyed Message Authentication Code (MAC) to protect message integrity or to construct key derivation functions.
For TLS 1.0 and 1.1, the construction used is known as HMAC; TLS 1.2 still use HMAC, but it also decalares that "Other cipher suites MAY define their own MAC constructions, if needed."
HMAC can be used with a variety of different hash algorithms. However, TLS 1.0 and TLS 1.1 use it in the handshaking with two different algorithms, MD5(HMAC_MD5) and SHA-1(HMAC-SHA). Additionla hash algorithm can be defined by cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for TLS 1.0 and TLS 1.1.
TLS 1.2 move away from the hard coded MD5 and SHA-1, SHA-256 is the default hash function for all cipher suites defined in TLS 1.2, TLS 1.1, TLS 1.0 when TLS 1.2 is negotiated. TLS 1.2 also declares that "New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function", which means that the hash functions used at handshakeing should be SHA-256 at least.
For the HMAC operations used to protect record data, the hash funtion is defined by cipher suites. For example, the HMAC's hash function of cipher suite TLS_RSA_WITH_NULL_MD5 is MD5.
TLS 1.0 and TLS 1.1 define three hash functions for HMAC, they are:
From TLS 1.2, new cipher suites may define their own MAC constructions except the default HMAC. TLS 1.2 defines five MAC algorithms, from the literal, it is straight forward to know the hash function used.
Pseudo-random function takes a key rule in TLS handshaking, it is used to calculate the master secret, calculate session keys, and verify the just negotiated algorithms via Finished message. TLS specifications define PRF based on HMAC.
For TLS 1.0 and TLS 1.1, the PRF is created by splitting the secret into two halves and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1, then exclusive-ORing the outputs of these two expansion functions together.
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);
TLS 1.2 defines a PRF based on HMAC as TLS 1.0/1.1, except that the hash algorithm used if SHA-256, "This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function."
Unlike TLS 1.0/1.1, the PRF of TLS 1.2 does not require to split the secret any more, only one hash function used:
PRF(secret, label, seed) = P_<hash>(secret, label + seed)
In the handshakeing message, ServerKeyExchage, for some exchande method, such as RSA, diffie_hellman, ec_diffie_hellman, ecdsa, etc., needs a so-called "signature" to protect the exchanged parameters.
TLS 1.0 and TLS 1.1 use SHA-1 ( or with MD5 at the same time) to generate the digest for the "signature". While for TLS 1.2, the hash function may be other than SHA-1, it is varied with the ServerKeyExchange message context, such as "signature algorithm" extension, the server end-entity certificate.
In TLS 1.0/1.1, there is no way for client to indicate the server what kind of server certificates it would accept. TLS 1.2 defines a extension, signature_algorithms, to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. The hash algorithm could be one of:
In TLS 1.0/1.1, a TLS server could request a serial of types of client certificate, but the "type" here refer to the "signature" algorithm, which does not include the hash algorithm the certificate should be signed with. So a certificate signed with a stonger signature algorithm, such as RSA2048, but with a weak hash funtion, such as MD5, would meet the requirements. That's not enough.
TLS 1.2 extends the CertificateRequest handshaking message with a addtional field, "supported_signature_algorithms", to indicate to the client which signature/hash algorithm pairs may be used in digital signatures. The hash algorithm could be one of:
In the last update of "Implementation Guidance for FIPSPUB 140-2", "The KDF in TLS is allowed only for the purpose of establishing keying material (in particular, the master secret) for a TLS session with the following restrictions, even though the use of the SHA-1 and MD5 hash functions are not consistent with in Table 1 or Table 2 of SP 800-56A: "
The NIST's policy on hash functions could be split into four principle. We discuss the profile according to the principles.
MD5 is not a FIPS approved hash functions, so first of all, the profile needs to disable all cipher suites with the MACAlgorith of MD5.
SHA-2 family of hash functions are completely compliant to the policy. The profile is safe to enabled the those cipher suites based on SHA-2
Those cipher suites with MAC algorithm of SHA-1 are addressed at the follow principles.
ServerKeyExchange depends on digital signature, the profile should stop using SHA-1 hash function for ServerKeyExchange handshaking message.
TLS 1.0 and TLS 1.1 use SHA-1 ( or with MD5 at the same time) to generate the digest for the "signature". There is no way to disable SHA-1 in ServerKeyExchange handshaking message. ServerKeyExchange is a optional handshaking message," it is sent by the server only when the server certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods:"
For TLS 1.0 and TLS 1.1, the profile needs to disable the above key exchange methods, for the purpose of preventing the ServerKeyExchange handshaking message occurred, by disabling the following cipher suites:
In TLS 1.2, the hash function used with ServerKeyExchange may be other than SHA-1, the following rules defined:
Per this rule, the profile requires that the "signature_algorithms" extension sent by client should include only SHA-2 hash algorithms or stronger, and must not include the hash algorithms: "none", "md5", and "sha1".
Per this rule, the profile requires that the server end-entity certificate must be signed with SHA-2 or stronger hash functions.
Note that, at present, the DSA(DSS) may only be used with SHA-1, the profile will not allow server end-entity certificate signed with DSA(DSS).
In TLS 1.0/1.1, there is no way for client to indicate the server what kind of server certificates it would accept. What we can do here is from the point of programming and managerment, the profile requires all server certificates must be signed with SHA-2 or stronger hash functions, and carefully checking that there is no certificate in the chain signed with none SHA-2-or-stronger hash functions.
In TLS 1.2, there is a protocol specified behavior, "signature_algorithms" extension. "If the client provided a 'signature_algorithms' extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension." Per the specific, the profile requires that the "signature_algorithms" extension sent by client should include only SHA-2 hash algorithms or stronger, and must not include the hash algorithms: "none", "md5", and "sha1"
However, "signature_algorithms" extension is not a mandatory extension in TLS 1.2, while server does not receive the "signature_algorithms" extension, it also needs to ship the NIST principle. So the profile still requires all server certificates must be signed with SHA-2 or stronger hash functions from the point of programming and management.
In TLS 1.0/1.1, there is no way for server to indicate the client it would accept what kind of hash algorithm used to signed the client certificates. What we can do here is from the point of programming and managerment, the profile requires all client certificates must be signed with SHA-2 or stronger hash functions.
TLS 1.2 extends the CertificateRequest handshaking message with a addtional field, "supported_signature_algorithms", to indicate to the client which signature/hash algorithm pairs may be used in digital signatures. The profile requires that the "supported_signature_algorithms" field must include only SHA-2 hash algorithms or stronger, and must not include the hash algorithms: "none", "md5", and "sha1".
Except the ServerKeyExchange, server Certificate and client Certificate messages, the hash function used in TLS protocols is for HMAC, KDF or RNG, which is allowed by the policy. Need no addtional profile for this principle.
TLS 1.0 and TLS 1.1 is totally depends on SHA-1 and MD5, there is no way to obey this principle. In order to fully remove the dependency on SHA-1/MD5, one have to upgrade to TLS 1.2 or later revisions.
Currently, Java SDK does not support TLS 1.1 or later. The proposals talked here are for TLS 1.0, which is implemented by the default SunJSSE provider.
JSSE has no APIs to disable a particular cipher suite, but there are APIs to set which cipher suites could be used at handshaking. Refer to SSLSocket.setEnabledCipherSuites(String[] suites), SSLServerSocket.setEnabledCipherSuites(String[] suites), SSLEngine.setEnabledCipherSuites(String[] suites) for detailed usage.
By default, SunJSSE enables both MD5 and SHA-1 based cipher suites, and those cipher suites that trigger ServerKeyExchange massage. In FIPS mode, SunJSSE enable SHA-1 based cipher suites only, however some of those cipher suites that trigger ServerKeyExchange also enabled. So, considering the above strict mode profile, the coder must explicit call SSLX.setEnabledCipherSuites(String[] suites), and the parameter "suites" must not include MD5 based cipher suites, and those cipher suites triggering handshaking message, ServerKeyExchange.
The strict profile suggest all certificates should be signed with SHA-2 or stronger hash functions. In JSSE, the processes to choose a certificate for the remote peer and validate the certificate received from remote peer are controlled by KeyManager/X509KeyManager and TrustManager/X509TrustManager. By default, the SunJSSE provider does not set any limit on the certificate's hash functions. Considerint the above strict profile, the coder should customize the KeyManager and TrustManager, and limit that only those certificate signed with SHA-2 or stronger hash functions are available or trusted.
Please refer to the section of X509TrustManager Interface in JSSE Reference Guide for details about how to customize trust manager by create your own X509TrustManager; and refer to the section of X509KeyManager Interface in JSSE Reference Guide for details about how to customize key manager by create your own X509KeyManager
Note that the above profile and suggestions are my personal understanding of the NIST's policy and TLS, they are my very peronal suggestions, instead of official proposals from official orgnization.
| [Firewall] paloalto network firewall (0) | 2010.11.19 |
|---|---|
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [DB] DB 암호제품 보안요구사항 (0) | 2010.05.27 |
| [기타] reCAPTCHA (1) | 2009.09.08 |
DB 암호제품 보안요구사항| [Firewall] paloalto network firewall (0) | 2010.11.19 |
|---|---|
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
| [기타] reCAPTCHA (1) | 2009.09.08 |
reCAPTCHA is a free CAPTCHA service that helps to digitize books, newspapers and old time radio shows. Check out our paper in Science about it (or read more below).
A CAPTCHA is a program that can tell whether its user is a human or a computer. You've probably seen them — colorful images with distorted text at the bottom of Web registration forms. CAPTCHAs are used by many websites to prevent abuse from "bots," or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs.
About 200 million CAPTCHAs are solved by humans around the world every day. In each case, roughly ten seconds of human time are being spent. Individually, that's not a lot of time, but in aggregate these little puzzles consume more than 150,000 hours of work each day. What if we could make positive use of this human effort? reCAPTCHA does exactly that by channeling the effort spent solving CAPTCHAs online into "reading" books.
To archive human knowledge and to make information more accessible to the world, multiple projects are currently digitizing physical books that were written before the computer age. The book pages are being photographically scanned, and then transformed into text using "Optical Character Recognition" (OCR). The transformation into text is useful because scanning a book produces images, which are difficult to store on small devices, expensive to download, and cannot be searched. The problem is that OCR is not perfect.
reCAPTCHA improves the process of digitizing books by sending words that cannot be read by computers to the Web in the form of CAPTCHAs for humans to decipher. More specifically, each word that cannot be read correctly by OCR is placed on an image and used as a CAPTCHA. This is possible because most OCR programs alert you when a word cannot be read correctly.
But if a computer can't read such a CAPTCHA, how does the system know the correct answer to the puzzle? Here's how: Each new word that cannot be read correctly by OCR is given to a user in conjunction with another word for which the answer is already known. The user is then asked to read both words. If they solve the one for which the answer is known, the system assumes their answer is correct for the new one. The system then gives the new image to a number of other people to determine, with higher confidence, whether the original answer was correct.
Currently, we are helping to digitize old editions of the New York Times.
In order to achieve our goal of digitizing books, we need your help.
If you run a website that suffers from problems with spam, you can put reCAPTCHA on your site. For some applications (such as Wordpress and Mediawiki), we have plugins that allow you to use reCAPTCHA without writing any code. We also have easy-to-use code for common web programming languages such as PHP.
If you get email spam we have a method that will help you to reduce it. Many spammers crawl the web looking for email addresses. When they see an email address on a web page, they send spam to the address. Mailhide allows you to safely post your email address on the web. Mailhide takes an address such as jsmith@example.com and turns it into jsm...@example.com. In order to reveal the address, a user must click on the "..." and solve a reCAPTCHA. If you use the Mailhide version of your email address, spammers won't be able to find your real email address and you'll get less spam.
| [Firewall] paloalto network firewall (0) | 2010.11.19 |
|---|---|
| [VoIP] Voice Over IP (0) | 2010.09.02 |
| [가상화] What actually is VMsafe and the VMsfe API? (0) | 2010.08.04 |
| [암호] TLS and NIST'S Policy on Hash Functions (0) | 2010.06.28 |
| [DB] DB 암호제품 보안요구사항 (0) | 2010.05.27 |
국정원-DB암호화_요구조건.pdf
