X509v3 can contain IP address field in subject Alternative Name extension.
As an application verifying the server's identity, how should the IP address field be validated?
If both DNS name and IP address are present? Is there a preference of one over the another?
What is the use of dirName field?
I read RFC 2818 earlier but must have missed this part.
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
My answer is based on my experience with TLS/SSL.
It's based upon the implementation of the certificate validation. To enforce IP address match, you have to implement that.
Whatever way you want. You could also check both.
Sorry no idea what this field does.
Have you checked the OpenSSL documentation?
Related
What do I use for the HMAC-SHA1 key when verifying the MESSAGE-INTEGRITY attribute of STUN Binding Requests from Chrome? (chrome is in the ICE-CONTROLLING role as the SDP offer is from an ICE-LITE peer)
RFC-5245 states:
To compute the message integrity for the check, the agent uses the
remote username fragment and password learned from the SDP from its
peer. The local username fragment is known directly by the agent for
its own candidate.
But it does not state how these are concatenated by the agent to form the HMAC SHA1 key
I have tried different combinations of ice-username:ice-password to form the key, but none seem to be able to generate the same hash as the message integrity attribute in the Binding request from chrome.
Does anyone know how the HMAC key is formed?
Requests for you will be signed with your local ice-pwd and the responses must be signed with it (as described ħere).
See RFC 5389 on how to compute the hash.
The ip 0 is the simplest alias I've found to localhost, and most browsers can open the page http://0/ without problem.
When trying the same on Chrome, it always redirect me to the search page.. like it does not recognize that 0, 0:80, 127.1, o 127.1:80 are valid IPs -- although it ask if you meant 0.0.0.0 or 127.0.0.1
Chrome can, however, open the page http://0.0.0.0 correctly
Every HTTP URL consists of the following, in the given order. Several schemes other than HTTP also share this general format, with some variation.
the scheme name (commonly called protocol, although not every URL scheme is a protocol, e.g. mailto is not a protocol);
a colon, two slashes;
a host, normally given as a domain name but sometimes as a literal IP address;
optionally a colon followed by a port number;
the full path of the resource;
The scheme says how to connect, the host specifies where to connect, and the remainder specifies what to ask for.
For programs such as Common Gateway Interface (CGI) scripts, this is followed by a query string and an optional fragment identifier.
The syntax is:
scheme://domain:port/path?query_string#fragment_id
So basically http is valid scheme, :// are valid colon and two slashes, but 0 is not valid domain name or IP address. However, the http://0.0.0.0 are valid scheme and literal IP address, that's why Google Chrome opens it.
The domain name or literal numeric IP address gives the destination location for the URL. A literal numeric IPv6 address may be given, but must be enclosed in [ ] e.g. [db8:0cec::99:123a]
The fact that other browsers "convert" http://0/ into localhost or 127.x.x.x is just browser implementation, it is not by the standard.
More details:
IETF and IETF
Wikipedia
I have two questions about SMTP RFC:
What value should I pass as the argument for the EHLO command if I don't have my own domain name?
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
I don't really undesrstand Section 4.1.3. Can you give me an example or rephrase it?
Which headers are required to send in the DATA section?
Thanks in advance.
Argument to EHLO in the absence of a domain name
Section 4.1.3 Address Literals of RFC 2821 says:
Sometimes a host is not known to the domain name system and
communication (and, in particular, communication to report and repair
the error) is blocked. To bypass this barrier a special literal form
of the address is allowed as an alternative to a domain name. For
IPv4 addresses, this form uses four small decimal integers separated
by dots and enclosed by brackets such as [123.255.37.2], which
indicates an (IPv4) Internet Address in sequence-of-octets form.
so a simple EHLO [123.255.37.2] suffices (with the actual IP address of your SMTP server of course). Or it could be a properly formatted IPv6 instead.
Required headers
Section 3.6. Field definitions of RFC 2822 says:
The only required header fields are the origination date field and
the originator address field(s). All other header fields are
syntactically optional.
so only From: and Date: are required.
If you don't have a domain name, you should use your IP address:
EHLO [192.168.1.1]
It's kind of a ridiculous requirement in the protocol seeing as how there's no real value in this piece of information. The server shouldn't trust it (obviously) and it is trivial for the server to get the IP address of the connecting client, anyway.
Scenario is this:
Parent.com can have a 'html only' file
and it has iframe with Iframe.com (php that i have full \controll ).
Question is this:
How can i check if iframe.com is loaded only by parent and cant be iframed by other domains
EDIT: Some solution suggest checking Referrer but this can be spoofed.
referer is as close as you can get before getting into really complicated territory.
While it can be spoofed, it can only be spoofed by the client. A third party website couldn't make the client spoof it.
That said, referer is optional. Browsers don't have to send it, and they tend not to under quite a lot of circumstances (such as when the referring document was served over HTTPS).
The following might work…
iframe.example.com uses server side code to request a token from framed.example.net, the request includes the ip address of the browser and a password authorising iframe.example.com to frame framed.example.net
framed.example.net generates a token and gives it to iframe.example.com, registering it against the ip address of the browser
iframe.example.com generates a URI with the token in the query string and uses it as the src to the iframe
framed.example.net checks that the token exists and the ip address in the record matches the ip address the request came from (the browser)
This will generate false negatives when the browser doesn't have a consistent ip address (such as when behind a group of proxy servers, which I seem to recall is quite common in cellular broadband), so I wouldn't recommend it.
On a form of my web app, I've got a hidden field that I need to protect from tampering for security reasons. I'm trying to come up with a solution whereby I can detect if the value of the hidden field has been changed, and react appropriately (i.e. with a generic "Something went wrong, please try again" error message). The solution should be secure enough that brute force attacks are infeasible. I've got a basic solution that I think will work, but I'm not security expert and I may be totally missing something here.
My idea is to render two hidden inputs: one named "important_value", containing the value I need to protect, and one named "important_value_hash" containing the SHA hash of the important value concatenated with a constant long random string (i.e. the same string will be used every time). When the form is submitted, the server will re-compute the SHA hash, and compare against the submitted value of important_value_hash. If they are not the same, the important_value has been tampered with.
I could also concatenate additional values with the SHA's input string (maybe the user's IP address?), but I don't know if that really gains me anything.
Will this be secure? Anyone have any insight into how it might be broken, and what could/should be done to improve it?
Thanks!
It would be better to store the hash on the server-side. It is conceivable that the attacker can change the value and generate his/her own SHA-1 hash and add the random string (they can easily figure this out from accessing the page repeatedly). If the hash is on the server-side (maybe in some sort of cache), you can recalculate the hash and check it to make sure that the value wasn't tampered with in any way.
EDIT
I read the question wrong regarding the random string (constant salt). But I guess the original point still stands. The attacker can build up a list of hash values that correspond to the hidden value.
Digital Signature
Its probably overkill, but this sounds no different than when you digitally sign an outgoing email so the recipient can verify its origin and contents are authentic. The tamper-sensitive field's signature can be released into the wild with your tamper-sensitive field with little fear of undetectable tampering, as long as you protect the private key and verify the data and the signature with the public key on return.
This scheme even has the nifty property that you can limit "signing" to very protected set of servers/processes with access to the private key, but use a larger set of servers/processes provided with the public key to process form submissions.
If you have a really sensitive "do-not-tamper" field and can't maintain the hash signature of it on the server, then this is the method I would consider.
Although I suspect most are familiar with digital signing, here's some Wikipedia for any of the uninitiated:
Public Key Cryptography - Security
... Another type of application in
public-key cryptography is that of
digital signature schemes. Digital
signature schemes can be used for
sender authentication and
non-repudiation. In such a scheme a
user who wants to send a message
computes a digital signature of this
message and then sends this digital
signature together with the message to
the intended receiver. Digital
signature schemes have the property
that signatures can only be computed
with the knowledge of a private key.
To verify that a message has been
signed by a user and has not been
modified the receiver only needs to
know the corresponding public key. In
some cases (e.g. RSA) there exist
digital signature schemes with many
similarities to encryption schemes. In
other cases (e.g. DSA) the algorithm
does not resemble any encryption
scheme. ...
If you can't handle the session on the server, consider encrypting the data with your private key and generating an HMAC for it, send the results as the hidden field(s). You can then verify that what is returned matches what was sent because, since no-one else knows your private key, no-one else can generate the valid information. But it would be much better to handle the 'must not be changed' data on the server side.
You have to recognize that anyone sufficiently determined can send an HTTP request to you (your form) that contains the information they want, which may or may not bear any relation to what you last sent them.
If you can't/won't store the hash server side, you need to be able to re-generate it server-side in order to verify it.
For what it's worth, you should also salt your hashes. This might be what you meant when you said:
concatenated with a constant long
random string (i.e. the same string
will be used every time)
Know that if that value is not different per user/login/sesison, it's not actually a salt value.
As long as you guard the "constant long random string" with your life then your method is relatively strong.
To go further, you can generate one time / unique "constant long random string"'s.
What you are describing is similar to part of the implementation required for what are termed canaries and are used to mitigate Cross Site Request forgery attacks.
Generally speaking, a hidden input inside a HTML form contains an encrypted value that is posted back with a HTTP request. A browser cookie or a string held in session contains the same encrypted value such that when the hidden input value is decrypted and the cookie/session value is decrypted, the unencrypted values are compared to each other - if they are not identical, the HTTP request cannot be trusted.
The encrypted value might be an object containing properties. For example, in ASP.NET MVC, the canary implementation uses a class that contains properties for the authenticated username, a cryptographically pseudo random value generated using the RNGCryptoServiceProvider class, the DateTime (UTC format) at which the object was created and an optional salt string. The object is then encrypted using the AES Encryption algorithm with a 256 bit key and decrypted with the same key when the request comes in.