Firstly, thank you for the taking the time out to read this post.
I'm running a demo development web server which is hosting my ASP.net Web API in IIS8.
My API is setup to work only via SSL, but I need the self signed SSL key to be 1024 bits rather than 2048 due to the limitations of my Microchip PIC Microcontroller that connects to it.
Can anyone advise me on how I can generate a self signed SSL certificate to be 1024 bits rather than the default 2048?
Please note that I am new to network/web programming so I'm trying to work things out as I go along. Thus far this is my first demo web applications.
Many thanks,
Rob
Ok I managed to create a key size of 1024 using microsofts selfssl tool which is part of their IIS6 Resource Toolkit.
This has solved my problem.
Related
I develop embedded firmware, that works with google cloud iot. I used this example https://www.st.com/en/embedded-software/x-cube-gcp.html?ecmp=tt9470_gl_link_feb2019&rt=um&id=UM2441 as a base for my firmware. I have a problem in understanding how the firmware should use root CA certification package (this is described here https://cloud.google.com/iot/docs/how-tos/mqtt-bridge#downloading_mqtt_server_certificates). Google suggest to use this package https://pki.goog/roots.pem to connect to mqtt server. But this file is too big for embedded firmware. In the stm32 example smaller file is used, it contents only 2 certificates:
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIF3jCCA8agAwIBAgIQAf1tMPyjylGoG7xkDjUDLTANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTAw
MjAxMDAwMDAwWhcNMzgwMTE4MjM1OTU5WjCBiDELMAkGA1UEBhMCVVMxEzARBgNV
BAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVU
aGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQCAEmUXNg7D2wiz0KxXDXbtzSfTTK1Qg2HiqiBNCS1kCdzOiZ/MPans9s/B
3PHTsdZ7NygRK0faOca8Ohm0X6a9fZ2jY0K2dvKpOyuR+OJv0OwWIJAJPuLodMkY
tJHUYmTbf6MG8YgYapAiPLz+E/CHFHv25B+O1ORRxhFnRghRy4YUVD+8M/5+bJz/
Fp0YvVGONaanZshyZ9shZrHUm3gDwFA66Mzw3LyeTP6vBZY1H1dat//O+T23LLb2
VN3I5xI6Ta5MirdcmrS3ID3KfyI0rn47aGYBROcBTkZTmzNg95S+UzeQc0PzMsNT
79uq/nROacdrjGCT3sTHDN/hMq7MkztReJVni+49Vv4M0GkPGw/zJSZrM233bkf6
c0Plfg6lZrEpfDKEY1WJxA3Bk1QwGROs0303p+tdOmw1XNtB1xLaqUkL39iAigmT
Yo61Zs8liM2EuLE/pDkP2QKe6xJMlXzzawWpXhaDzLhn4ugTncxbgtNMs+1b/97l
c6wjOy0AvzVVdAlJ2ElYGn+SNuZRkg7zJn0cTRe8yexDJtC/QV9AqURE9JnnV4ee
UB9XVKg+/XRjL7FQZQnmWEIuQxpMtPAlR1n6BB6T1CZGSlCBst6+eLf8ZxXhyVeE
Hg9j1uliutZfVS7qXMYoCAQlObgOK6nyTJccBz8NUvXt7y+CDwIDAQABo0IwQDAd
BgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rIDZsswDgYDVR0PAQH/BAQDAgEGMA8G
A1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEMBQADggIBAFzUfA3P9wF9QZllDHPF
Up/L+M+ZBn8b2kMVn54CVVeWFPFSPCeHlCjtHzoBN6J2/FNQwISbxmtOuowhT6KO
VWKR82kV2LyI48SqC/3vqOlLVSoGIG1VeCkZ7l8wXEskEVX/JJpuXior7gtNn3/3
ATiUFJVDBwn7YKnuHKsSjKCaXqeYalltiz8I+8jRRa8YFWSQEg9zKC7F4iRO/Fjs
8PRF/iKz6y+O0tlFYQXBl2+odnKPi4w2r78NBc5xjeambx9spnFixdjQg3IM8WcR
iQycE0xyNN+81XHfqnHd4blsjDwSXWXavVcStkNr/+XeTWYRUc+ZruwXtuhxkYze
Sf7dNXGiFSeUHM9h4ya7b6NnJSFd5t0dCy5oGzuCr+yDZ4XUmFF0sbmZgIn/f3gZ
XHlKYC6SQK5MNyosycdiyA5d9zZbyuAlJQG03RoHnHcAP9Dc1ew91Pq7P8yF1m9/
qS3fuQL39ZeatTXaw2ewh0qpKJ4jjv9cJ2vhsE/zB+4ALtRZh8tSQZXq9EfX7mRB
VXyNWQKV3WKdwrnuWih0hKWbt5DHDAff9Yk2dDLWKMGwsAvgnEzDHNb842m1R0aB
L6KCq9NjRHDEjf8tM7qtj3u1cIiuPhnPQCjY/MiQu12ZIvVS5ljFH4gxQ+6IHdfG
jjxDah2nGN59PRbxYvnKkKj9
-----END CERTIFICATE-----
I have found this 2 certificates in google package https://pki.goog/roots.pem. Does this mean that I can use any certificate from package? And what will happen after updating active certificate in google cloud, as described here Why won't my Raspberry Pi connect to Google Cloud IoT?. I have already faced a problem with connection to cloud for a some days, but now it works ok again.
I saw that google suggest another way for embedded devices (long-term MQTT domain with minimal root CA set), but it requires to do some changes in firmware and it is difficult now for me.
I see that you mentioned that changing the firmware is hard, and that is true, but there isn't a good way other than this because of the rotation of the general root certificate. Even if you trim the currently unused certs from the CA file, once rotation happens, and it happens frequently, it'll break connectivity.
From this page: https://cloud.google.com/iot/docs/how-tos/mqtt-bridge
Google's minimal root CA set (<1 KB) for mqtt.2030.ltsapis.goog. The minimal root CA set includes a primary and backup certificate.
This set is for devices with memory constraints, like microcontrollers, and establishes the chain of trust to communicate with Cloud IoT Core only.
Devices with the minimal root CA set communicate with the Cloud IoT Core via long-term support domains.
This set is fixed through 2030 (the primary and backup certificates won't change). For added security, Google Trust Services may switch between the primary and backup certificates at any time without notice.
Which is what you need to use for embedded systems that you don't want to deal with rotating certificates every time the core Google root CA rotates certificates. Here are the links for the primary and backup root certs:
https://pki.goog/gtsltsr/gtsltsr.crt
https://pki.goog/gsr4/GSR4.crt
Note also that this uses that different endpoint for this certificate. The general (128K) root cert is used when connecting to mqtt.googleapis.com, and the smaller long-term support root CA uses mqtt.2030.ltsapis.goog so you'll need to change your firmware to account for this.
Hello Corda experts: I have a question about Conclave beta 3. I downloaded conclave SDK hello world project, and ran it according to conclave document successfully. But when I tried to use RestTemplate to access an external https API from the enclave, it is failed. And the error message is "java.security.NoSuchAlgorithmException: Default SSLContext not available". Since the default JVM for enclave is Avian, I doubt that maybe Avian doesn't support SSL. Does any expert know the root cause and how to solve it? Thanks very much.
At this time Conclave doesn't support outbound SSL connections. It's something we'd like to support and is a high priority but it must be done very carefully. For example, we will have to ship a root cert store with the enclave embedded in the binary (or a signed version that's injectable by the host), there are questions about how to handle expiry checking given that the host controls the clock, whatever credentials are used to access the external service (if any) need to be securely sealed and stored, it will only make sense to support OCSP Stapling as a form of revocation checking with all others needing to be disabled and so on.
You don't technically need us to solve these issues for you. You can load the SSLEngine and relay packets from it in and out of the host using the call mechanism. It'd be a bit awkward but should be possible.
I am still quite new to cryptography, so please excuse any rookie mistakes. I am shure this has been asked a couple of times, but I have no idea what to search for.
So, I have a server, which receives commands over http from my smartphone. Currently everything is encrypted using AES with a password, which can be set in the server's config.
The problem is that, when someone intercepts my requests, he cannot decrypt the commands, but he can resend the encrypted command to my server.
Two solutions I imagine are:
encrypt a timestamp within the command, so they are invalid after a period of time, but with the disadvantage that still (within that period) the commands can be resent.
the server sends some random stuff to the client, which must encrypt that and send the encrypted stuff back (I think that will kill my http approach)
I am shure there are better ways (maybe another algorithm?), any help is welcome.
Again, I don't have much experience with cryptography and programming is just a hobby :D
Please do not try to reinvent secure communication. SSL and SSH are two very widely used, and very good protocols for secure communication, both of which will address replay, as well as many other security issues that you've not yet thought of (re-ordering, removing messages, inserting messages from one place into another, etc).
It seems you need both encryption and authentication.
As stated by others, please only use SSL (HTTPS) for encryption for HTTP requests. SSL is exceptional for encryption. SSL can do authentication but there are better solutions for authentication of users from smartphones.
For authentication of the user, there are many options. For smartphone connections I suggest you also not invent your own authentication protocol and use tried and tested solutions such as OpenID and OATH. There are many libraries that support this. Using such protocols opens the possibility of authenticating users using their existing Google, Facebook, Twitter accounts etc.
First of all thanks for taking the time to read my question. Here is what I am trying to accomplish followed by what I have so far on this.
What I want to do is create a Windows application (or server of sorts) that would listen for requests from an ASP.NET application. The windows application would be installed and would listen for messages from ASP.NET application and then do some processing. The flow is like this:
A user downloads the desktop application and registers their IP address on my web site. After downloading the desktop app, the ASP.NET application can then send requests to that particular desktop client for further processing. I think further processing is independent of the resolution in this case that's why i have skipped over details on what processing would be done. But if you think it is important, please let me know and I will add those details as well.
I have looked into creating a TCP server that would listen for requests. Because the user has already registered their IP address on my web site, my web site assigns them a unique identifier and stores the ID alongwith IP address in database. Now, the ASP.NET site can send requests to that desktop application.
I have looked into creating a TCP server for this purpose. While researching I also came across PNRP and it seems something like what I am trying to do.
Can you guys recommend some solutions or where I should be looking at for this scenario? Should I create a simple TCPLISTENER or may be go with PNRP approach? Or something else?
The basic requirement is for a web application to be able to communicate with a desktop application. The web application would be servicing numerous users and each user would have a desktop application installed. Which user for which desktop client question would be addressed by the web application that would maintain a database of unique user id's and their corresponding IP Address.
Thanks in advance for your help.
You could use .NET remoting or a web-service in the desktop app. Use WCF or WSE for the latter. You can use COM to add windows firwall rules.
Whatever you do, take firewalling/NAT into account. It might be easier for the client application to poll the server (initiate the connection) otherwise you open a can of worms by trying to have a remotely-accessible server in your user's computer without having to do some very manual configurations on the user's networking equipment.
Once you have that part sorted out, what I used in your situation was .NET Remoting. At the time WCF had not come out and when it did it was to crippled for my needs. TCP IP sockets were too raw (I had to write too much code) and so Remoting solved my problem ideally (a hand full lines of code to set up the connection, and everything was automatic from there on).
EDIT: I use an excellent third party library that makes Remoting even more flexible (flexible enough that I am still waiting for WCF to catch up with the featureset so that I stop using Remoting, and no luck yet!). Check out http://www.genuinechannels.com/ to see all the features they have. It includes making calls from server to client, and that sounds exactly like what you need to do. Check it out.
Some phones only prompt the user for permission the first time a connection is made. Others pop up the permission prompt whenever the MIDlet attempts to make a HTTP connection! What are the options if we want to suppress the prompt?
Can we sign the JAR using only one CA (Certificate Authority) and have it work on all devices? Do we have to pay for a signature on every release?
Is it an option to create our own CA certificate and tell our customers to install it on there device?
Alternatively, it seems that plain socket connections do not suffer so. Is there a free implementation of HTTP on top of TCP for J2ME?
Some phones allow you to change the setting manually to set once per session. Or try adding
MIDlet-Permissions: javax.microedition.io.connector.http
to the jad file.
Yes, if the build is signed with the root certificate that is available on most devices, Verisign Class 3 certificate, for example
As a security measure, devices don't allow you to install your own certificates, even if it is obtained from a CA.
Plain socket connections may add overhead in processing of the data in the client side. Also some security issues are also involved.
Signing the JAR is not guaranteed to suppress these prompts on all handsets and all networks. It may work on some. AFAIK you usually need to sign per build; so if you use the same build on many handsets, you need to sign only once.
You could write your own implementation of HTTP over sockets, but beware that Socket implementations do not allow access to ports 80 and 8080 (again AFAIK).
Your best option when experiencing multiple prompts for HTTP is to direct the user to the MIDlet permissions setting in their handset menu; this should be changed to "ask once".
HTH,
funkybro
Java Verifieds UTI root certificate is not on all handsets/network combinations, the same is true for other domains in the trusted third party such as Verisign and Thawte (for these bodies in particular Motorola devices)
It is fair to say that the UTI certificate is probably the one to choose to give you the most coverage across handsets
To suppress the HTTP connection prompt, signing an app is the only option. Another would be to get preload on a pre-market phone, but even the handset manufacturers require signed jad/jars.
Making a set of jad/jar work on different devices is not dependent on signing but how you design an app. If you can address this then yes, you can have one signed jad/jar work on multiple devices.
I do not know about creating our own certs and asking customers to install them. I dont think it works as I dont think it is possible.
HTTP over TCP is a fairly easy implementation, provided you know what you are doing, but I dont know of any free implementations of it.
Get it Java Verified and you will find that on all networks and phones - the user will get prompted only once each time they start the app to authorise a connection.