I need to know if many people are on my site with a browser using RC4. The main culprits being IE6,7,8 on XP.
Apparently by enabling SChannel logging I can do this and then read the results in the event log.
To test I have enabled SChannel Logging on my test server but I can't see where in the event viewer I should be able to see any of the info this new logging provides.
The test server is using a self-signed cert and I've accessed it using IE7 on a 'secure' page, but there's nothing in the event logs, or at least nothing I can see.
Does anyone know where I should be looking to see what cipher the user is using?
I would suggest that you use nets trace command to log and later open the ETL file with Windows Performance Analyzer or NetMon, sources from Serverfault and Microsoft.
Regarding your self signed certificate I advice you to get a free public certificate from Let’s Encrypt. I hope my answer solves your problem, best regards Gillsoft AB.
netsh trace start capture=yes
What you did is essentially as much as you can do, apart from capturing and filtering the HTTPS packets.
To what level did you bump your SChannel loggin? According to the official MS page the best for you would be 0x0007 (i.e., 0x0001 | 0x0002 | 0x0004). The log messages themselves should be in the System event log.
Related
I need it for security testing. My purpose is to check, how the application would behave, if the adversary presents a certificate with a wrong Common Name (CN) and/or SubjectAltName, but signed by a correct CA.
I believe that the application in test uses HostnameVerifier incorrectly and need to prove it.
Here is an official answer from Telerik (Eric Lawrence):
Click Rules > Customize Rules. Scroll to OnBeforeRequest.
Inside that function, add the following:
if (oSession.HTTPMethodIs("CONNECT") &&
oSession.HostnameIs("siteIcareabout.com"))
{
oSession["X-OverrideCertCN"] = "badhostname.net";
}
Save the file and restart the browser if it had previously established any connections to https://siteIcareabout.com.
==========================
I checked it and it works.
Vanilla Fiddler lacks a mechanism to do this, so you would need to use an external tool or plugin. Some examples are cataloged here.
Of course, any certificate you generate will be signed by the Fiddler root cert, so the platform you're running the application from will need to trust that certificate
This may be a silly question but is client side application insights safe from spoofing? Microsoft ask you to add a bit of JavaScript to your HTML page that needs recording and part of this contains a hard coded instrumentation key (not a real key below!):
instrumentationKey: "3D486E8C-BDEF-43AB-B27A-9D3F9D42EC14"
There doesn't seem to be any other relationship between Url and key or any mechanism to prevent spoofing of this key client side (i.e. randomly generating the key with different numbers and submitting the page).
This wouldn't cause any damage, but it would be annoying to the receiver of the incorrect monitoring data, which may well be all someone wants to do "because they can".
Have I missed something fundamental as to why this is not possible?
This is absolutely correct that anyone can log misleading or garbage data to anyone’s AI account if they know the instrumentation key. This is also correct for most web other analytics systems: the request to log information is sent unauthenticated and anyone with sufficient skill can emulate a valid user data. The fact that AI has instrumentation key embedded on the page does not make it easier because anyone using web traffic monitor tool like Fiddler can still intercept and emulate the requests, even if instrumentation key was not embedded on the page.
If you suspect that a malicious user will purposefully log misleading data using your AI key, you should use caution and validate if the data makes sense before making your business decisions, for example from how many users was the data obtained and over what period of time, and whether your client-side page view data matches the server-side requests data.
While not exactly a duplicate, i believe the answer is pretty much the same as this one:
How does Google Analytics prevent traffic spoofing
AI doesn't know how or where you're using your key, so how would they know which traffic is legitimate and which is not?
+1 to Alex's answer. FYI, this is the official answer from Azure Monitor: My Instrumentation Key is visible in my web page source
TL;DR:
Yes, data can be skewed but not stolen
It is a common practice
To mitigate the impact, you could set up two separate app insights resources: one for client, the other for server
To overcome the issue, you set up a custom API and forward telemetry data to app insights.
I've been asked to support 2 URLs for JMX access to our server:
A secure one (service:jmx:rmi://localhost/jndi/rmi://localhost:2020/jmxrmi)
An insecure one: (service:jmx:rmi://localhost/jndi/rmi://localhost:2020/insecure-jmxrmi)
The insecure one is primarily for demo purposes - no it won't be used during production.
I can create a custom ConnectorServer for /jmxrmi and provide an interceptor to use our security mechanism to verify credentials. If I just create a vanilla second ConnectorServer (no 'env' properties), however, using jconsole -debug to access it initially tries secure access, and puts up the dialog about that failing, then asking if I want to try it insecurely.
The docs I've read from Oracle/Sun indicate that I can disable password auth and SSL using a couple of command-line -D switches. But then does that not mess with the /jmxrmi secure access?
How do I support both secure and non-secure connections at the same time? Note that I don't need them using the same URL, of course.
Thanks!
This is a tough one. When you disable auth and SSL you do it per JVM.
The JMXRMP protocol can not distinguish between secured and non-secured connection. You either set up the security and it will be used or not. I think the best shot would be using a custom ConnectorServer and put up with the messages JConsole produces.
I am using the Authorize.Net DPM (Direct Post Method) integration on one particular eCommerce system that I manage.
We have renewed our SSL certificate for this site, and the new SSL cert uses SHA-256 rather than SHA-1, as is recommended for additional security.
However, now AUthoeize.Net can no longer post back to my server. When processing a payment, I receive the message:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
from the URL https://secure.authorize.net/gateway/transact.dll, rather than being sent back to my code where I can display the "payment successful" page. Upon reseraching this, I believe the issue is that Authorize.Net's servers don't support SHA-2 certificates:
Does anyone know if Authorize.net accepts the newer SHA2 encryption? Our production servers which use this type of certificate do not receive the RelayResponse.
We found an article on SHA2 encryption issues with WIN2003 servers KB968730. We know Authorize.net uses Win 2003 servers based on http headers, which tell us IIS6.0.
We just established that is a real issue with Authorize.Net. We were able to purchase a SHA1 certificate and we are now able to receive the Relay Response from Authorize.NET. Authorize.NET Relay Response does not handle G2/SHA256 certificates. This will become a major issue in 2014 when SHA1 certifictions will not be obtainable from vendors eg. GoDaddy etc.
I have contacted Authorize.Net support but they seem to not even understand how their own product works, because the responses I get from them make no sense:
We have no announcements regarding the use specifically of SHA-2 hashes to connect to our servers at this time. Notices of any changes to the integration methods will be available in the merchant interface, as well as on the developer center at developer.authorize.net if that change occurs.
I'm not connecting to their servers. They're connecting to my server... so since their support is of no help... how can I resolve this? Is it safe/wise to not use SSL for the x_relay_url DPM postback URL? That seems to be the safest suggestion but I am hesitant to do this.
The resolution I went with was to get an SSL certificate with an SHA-1 signature algorithm, rather than SHA-2.
The issue that SHA-2 certs are rejected by Authorize.net's servers has been reported to their systems engineering team, but I do not know if they will correct this.
I have just run into this problem myself.
I can verify that in my tests, when I switched my x_redirect_url parameter to use a non-ssl host it started redirecting properly back to my site. I can also verify that Authorize.net support does not know how their own products work; I had to explain to them how the x_redirect_url works and got no usable info from them regarding any kind of validation they might be doing on the redirect URL that could cause their system to refuse to redirect.
I thought it was due to a domain name mismatch in my dev environment so I just forced my dev environment to use a non-ssl redirect. Then when I launched my new site I discovered that the problem persisted with SSL redirects on my production site, so I've just switched it back to using non-ssl redirects on my production site temporarily until I get this sorted out.
I have not yet regenerated my ssl cert because I'm not sure if it's using SHA1 or SHA2 and I don't want to regenerate it and reinstall it until I'm sure the cert is SHA1.
I'm having a hard time determining which SHA version it uses because the Thumbprint Algorithm shows SHA1, but then I see SHA256RSA for the Signature Algorithm and sha256 for the Signature Hash Algorithm. So, if anyone knows if that means I have SHA1 or SHA2, please reply to this reply.
So I came across this new tag in HTML5, <keygen>. I can't quite figure out what it is for, how it is applied, and how it might affect browser behavior.
I understand that this tag is for form encryption, but what is the difference between <keygen> and having a SSL certificate for your domain. Also, what is the challenge attribute?
I'm not planning on using it as it is far from implemented in an acceptable range of browsers, but I am curious as to what EXACTLY this tag does. All I can find is vague cookie-cutter documentation with no real examples of usage.
Edit:
I have found a VERY informative document, here. This runs through both client-side and server-side implementation of the keygen tag.
I am still curious as to what the benefit of this over a domain SSL certificate would be.
SSL is about "server identification" or "server AND client authentication (mutual authentication)".
In most cases only the server presents its server-certificate during the SSL handshake so that you could make sure that this really is the server you expect to connect to. In some cases the server also wants to verify that you really are the person you pretend to be. For this you need a client-certificate.
The <keygen> tag generates a public/private key pair and then creates a certificate request. This certificate request will be sent to a Certificate Authority (CA). The CA creates a certificate and sends it back to the browser. Now you are able to use this certificate for user authentication.
You're missing some history. keygen was first supported by Netscape when it was still a relevant browser. IE, OTOH, supported the same use cases through its ActiveX APIs. Opera and WebKit (or even KHTML), unwilling to reverse-engineer the entire Win32 API, reverse-engineered keygen instead.
It was specified in Web Forms 2.0 (which has now been merged into the HTML specification), in order to improve interoperability between the browsers that implemented it.
Since then, the IE team has reiterated their refusal to implement keygen, and the specification (in order to avoid turning into dry science fiction) has been changed to not require an actual implementation:
Note: This specification does not
specify what key types user agents are
to support — it is possible for a user
agent to not support any key types at
all.
In short, this is not a new element, and unless you can ignore IE, it's probably not what you want.
If you're looking for "exactly" then I'd recommend reading the RFC.
The keygen element is for creating a key for authentication of the user while SSL is concerned about privacy of communication and the authentication of the server. Quoting from the RFC:
This specification does not specify how the private key generated is to be used. It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC) structure, the server will generate a client certificate and offer it back to the user for download; this certificate, once downloaded and stored in the key store along with the private key, can then be used to authenticate to services that use TLS and certificate authentication.
Deprecated
This feature has been removed from the Web standards. Though some
browsers may still support it, it is in the process of being dropped.
Avoid using it and update existing code if possible. Be aware that
this feature may cease to work at any time.
Source
The doc is useful to elaborate on what is the keygen element. Its requirement arises in WebID that maybe understood to be part of Semantic Web of Linked Data as seen at https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#creating-a-certificate 2.1.1
This might be useful for websites that provide services, where people need to pay for the service, like video on demand, or news website for professionals like Bloomberg. With this keys people can only watch the content in their computer and not in simultaneous computers! You decide how data is stored and processed. you can specify a .asp or .php file that will receive the variables and your file will store that key in the user profile. This way your users will not be able to log in from a different computer if you want. You may force them to check their email to authorize that new computer, just like steam does. Basically it allows to individualize service access, if your licensing model is per machine, like Operating System.
You can check the specs here:
http://www.w3.org/TR/html-markup/keygen.html